О роли тестовых заданий в жизни разработчика

    Сколько технических интервью было у вас в жизни?


    За последние пять лет я побывал на 35 технических интервью всех вообразимых видов и специфик — от казахстанских стартапов по коллективной закупке мяса на зиму до немецких и американских финтех-сервисов и банков; с уклонами в программирование, деливери и управление; удаленных и в офисе; ограниченных и неограниченных по времени; стрессовых и расслабленных, на разных языках.

    Это, вкупе с ~20 собеседованиями, которые я провел сам в качестве нанимателя — достаточное число, чтобы стать королем собеседований сделать следующее наблюдение (изначально совершенно неочевидное) и утвердиться в нем: я убежден, что во многом благодаря такому количеству собеседований, начинающему походить на маргинальную привычку, я изучил свой стэк на профессиональном уровне и стал конкурентоспособным специалистом при том, что до этого уже работал 10 лет в веб-разработке.

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

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

    Почему качество наших фундаментальных знаний оставляет желать лучшего?


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

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

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

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

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

    Применительно к моему родному JavaScript есть хороший пример — если бы не появился React.JS, 98% JavaScript-программистов успешно продолжали бы жить в блаженном неведении о том что такое bind — спустя 20 с лишним лет после его появления — и продолжали бы впадать в недоумение, получая вопросы о нем на собеседованиях, а работать с ним продолжали бы только те, кто изобретает все эти высокоабстрактные библиотеки, фреймворки и модули. Сегодня, благодаря реакту, это число удалось сократить, по ощущениям, до 97%.

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

    Чем чреват недостаток фундаментального знания языка


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

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

    Будущее проектов, разрабатываемых с таким, пусть по незнанию, но безответственным подходом, прозаично и непродолжительно: существенные потери времени на ровном месте, сбои, финансовые и репутационные потери и, как следствие, снижение энтузиазма к продолжению сотрудничества.

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

    ActualizeBot


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

    В боте на данный момент есть 3 простых функции:

    • Подписка на тот или иной язык / фреймворк с тем, чтобы получать по нему новые задачи. Вы подписываетесь и по мере поступления, задач, получаете их в ежедневной рассылке
    • Публикация задачи или тестового задания — In my book they say sharing is caring
    • Великолепный генератор имен, с помощью которого вы сможете подобрать оптимальную подпись для публикуемого вами текста задания, включая словари женского рода, не лишенные феминитивов

    На данный момент на выбор предлагаются следующие языки: JavaScript, Java, Python, PHP, MySQL. Выбор несколько ограничен в связи с границами моего понимания. Надеюсь с помощью хабрасообщества пополнить этот перечень.

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

    Вкратце о технической реализации


    Этот бот — один из нескольких небольших проектов на которых я довожу первую публичную версию моего опенсорсного минифреймворка для разработки ботов с комплексной структурой, любовно именованного Hobot и доступного в NPM для хардкорщиков.

    Фреймворк построен на базе Telegraf.JS и TypeScript, его ноль-ноль-первую версию, оснащенную примером использования, можно посмотреть на гитхабе и сразу же попробовать. Вскоре я выгружу расширенную и причесанную для человека со стороны версию 0.0.2 и посвящу ему (хоботу) отдельную статью. Буду рад если для кого-то он окажется столь же актуальным, сколь и для меня.

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

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 36

      +9
      Это, вкупе с ~20 собеседованиями, которые я провел сам в качестве нанимателя — достаточное число, чтобы стать королем собеседований сделать следующее наблюдение (изначально совершенно неочевидное) и утвердиться в нем: я убежден, что во многом благодаря такому количеству собеседований, начинающему походить на маргинальную привычку, я изучил свой стэк на профессиональном уровне и стал конкурентоспособным специалистом при том, что до этого уже работал 10 лет в веб-разработке.

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

      Проблема несколько в другом. Дело в том, что текущий объём используемых технологий в повседневной работе достаточно большой. Настолько большой, что приходится очень часто прибегать к разного рода справочникам (stackoverflow, zeal, wikipedia). А на собеседовании обычно ситуация выворачивается так, что только кандидат тупой, потому что до сих пор не запомнил всё это.
      Будущее проектов, разрабатываемых с таким, пусть по незнанию, но безответственным подходом, прозаично и непродолжительно: существенные потери времени на ровном месте, сбои, финансовые и репутационные потери и, как следствие, снижение энтузиазма к продолжению сотрудничества.

      Всё у вас в кучу. Будущее проекта зависит в основном от умения его протолкнуть, а не правильности стека технологий. А выгорание сотрудника зависит от совокупности факторов, большая часть из которых связана с организацией труда, а не от того, есть ли на проекте jQuery.
        +1
        А на собеседовании обычно ситуация выворачивается так, что только кандидат тупой, потому что до сих пор не запомнил всё это.
        Лучше и не скажешь.
          +1
          Такая ситуация говорит только об одном: интевьюер неопытный или слишком самовлюбленный. Бегите. Если же вы не отвечаете на вопрос, а он спокойно переходит к следующему (возможно ответив на него самостоятельно) — скорее всего Вам повезло. Взвешиваться будет не результат ответа на 1 вопрос, а по совокупности.

          Почему-то большая часть программистов (мнение сложилось как раз по результатам чтения комментариев на Хабре) считают что техническое собеседование — бесполезная трата времени. Это не так. Вашему потенциальному работодателю нужно оценить Ваш уровень знаний. Да, 90% этих знаний нормальный программист использует не осознанно, но в этом случае будет оцениваться именно наличие тех 10%. Все просто, если вы не можете ответить ни на 1 из 30 поставленных вопросов уровня «что такое рекурсия?», должен возникнуть вопрос, а работали ли вы разработчиком вообще те 10 лет, заявленные у вас в резюме? И, если таки работали, то что вообще отложилось у вас в голове?
          Плюс, отвечая на вопросы про люки, вы демонстрируете как умеете излагать свои мысли. Ответ по википедии/доке — малоинтересен. Куда больше интересны рассуждения с выходом на решение. Но это скорее уже не про тупые вопросы, а про тупые задачи.

          И да, я спрашиваю, например, про паттерны. И нет, это интересно не чисто в академическом срезе, поскольку постановка задачи может выглядеть как «вот к этому и вон тем объектам сделай общий фасад, а вот эти вот дурацкие состояния вообще убери нафиг и напиши нормальный обзервер!». И, вы не поверите, мне хочется чтобы меня понимали! И мне нужно оценить, КАК БЫСТРО разработчик начнет понимать меня, если даже вообще ничего не понял сейчас.
            +1
            Куда больше интересны рассуждения с выходом на решение. Но это скорее уже не про тупые вопросы, а про тупые задачи.

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

                      Работнику так же будет невыгодно увольняться с текущей работы если нет высокой уверенности что испытательный пройдет.
                        0
                        Я не говорю, что нужно отменить собеседования. Можно побеседовать 2 часа и пощупать человека на предмет комфортно с ним будет работать или нет. Есть рекомендации. Есть неотвеченные вопросы, которые можно попросить ответить в письменной форме.
                        В совокупности всё вышеописанное уже неплохой источник информации для принятия решения.
                        Я говорю о том, что часто просят порассуждать о темах, связанных с программированием, но которые потом кодить не надо. и вот я против таких рассуждений, по крайней мере оперативных в рамках беседы.
                        Я предпочту тестовое задание, если уж хочется проверить как я думаю.
                          0
                          У вас очень специфический подход
                          90% моих коллег, включая меня, вообще против тестовых заданий и никогда их не делают

                          Поясню
                          Я довольно давно уже не джуниор и, если меняю работу, то тоже расчитываю на позицию архитектора/лида
                          Меня бессмысленно спрашивать рекурсии и просить написать шаблон приложения — это только покажет некомпетентность интервьюера
                          Мое резюме всегда в открытом доступе и я всегда в поиске
                          У меня нет времени на то, чтобы каждому потенциальному варианту посвящать часы на тестовое задание
                          С другой стороны, я могу рассказать что я думаю о правильной архитектуре приложения и паттернах разработки за пятнадцать минут
                          И да, если ваше собеседование длится 2 часа — от вас я тоже убегу
                            0
                            90% моих коллег, включая меня, вообще против тестовых заданий и никогда их не делают

                            Если вы (чисто для примера) сидите на PHP 10 лет, то тестовые делать глупо. Но как только вы захотите радикально поменять стек, например геймдев на Си++, то и ЗП придётся попросить поменьше и тестовых поделать. Так что тут зависит от ситуации.

                            И да, если ваше собеседование длится 2 часа — от вас я тоже убегу

                            Собеседование — не пытка. Если реченька льётся, то нет смысла её останавливать. Если идёт с трудом, то можно и за 30 мин завершить.

                              0
                              Но как только вы захотите радикально поменять стек
                              Обычно люди не меняют стек настолько радикально
                              Даже перейти с PHP на C# или .Net Core — нормально, но ваш пример какой-то категорически искусственный и попахивает дауншифтингом
                              Собеседование — не пытка
                              Не пытка, но испытание
                              Есть вполне четкие стандарты, обусловленные человеческой психологией и эффективностью самого процесса
                              Продолжительность нормального TI у подготовленного интервьюера — около 45 минут, максимум — час, если вы выходите за эти рамки, то, почти всегда, это значит, что интервьюер вы не очень или сами не знаете чего хотите

                              Дело тут все в том, что есть распространенная ошибка интервьюеров: они пытаются выявить уровень энциклопедических знаний у кандидата во всех смежных областях
                              Реально, если вы сами специалист в обсуждаемой сфере, вам бывает достаточно задать 3-5 вопросов чтобы оценить общий уровень кандидата, как практического специалиста и еще примерно столько же, чтобы понять подходит ли он для проекта и команды
                                0
                                Обычно люди не меняют стек настолько радикально

                                Меняют, это вообще лично мой пример. И среди моих знакомых я не одинок. Даже Go после Perl потребует уступить в ЗП и тщательной проверки кандидата. Мало ли он свой перл стиль будет в Go вставлять, а обычно так и происходит.

                                Даже перейти с PHP на C# или .Net Core — нормально, но ваш пример какой-то категорически искусственный и попахивает дауншифтингом

                                Вам то перейти может и нормально, а вот принимающая команда будет смотреть на вас косо. Нет боевого опыта на C# в год хотябы? Значит на кончиках пальцев нет чувства нюансов.

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

                                Реально, если вы сами специалист в обсуждаемой сфере, вам бывает достаточно задать 3-5 вопросов чтобы оценить общий уровень кандидата, как практического специалиста и еще примерно столько же, чтобы понять подходит ли он для проекта и команды

                                Кандидат может быть скрытым мудаком, который в первый день открытия кода скажет, что вы все тут мудаки и надо всё переписать. В 3-5 вопросов это можно не выяснить.
                                  +1
                                  Обычно люди не меняют стек настолько радикально

                                  Свалил с 1с на андроид. Не исключено что когда нибудь уйду в бекенд (а андроид все же фронт). А может и вовсе таки соберусь, подтяну математику со статистикой и пойду в какой нибудь анализ данных.
                                  Да даже в мобилках когда/если буду менять андроид на флаттер таки на слово не поверят что во флаттере шарю.
                          0
                          К сожалению, бывают случаи, когда разработчик только через 1.5-2 месяца начинает выдавать первый код. Это совсем не проблема разработчика (про бюрократию в крупных компаниях слышали?), но на собеседовании при этом приходится принимать практически финальное решение.
                            0
                            Ну тогда да конечно, но я бы оттуда валил.
                      0
                      Я готов подумать над проблемой по дороге домой и напишу аргументированный ответ.

                      С одной стороны было бы удобно, с другой у работодателя не будет уверенности а ваш ли это ответ.
                      Эту проблему уже давно решили преподаватели ВУЗов — «Решил? Теперь расскажи ход решения!»
                      Человек на собеседовании может «не раскрыться» в силу разных обстоятельств.

                      Идеальное техническое собеседование, на мой взгляд, выглядит так.
                      1. Даются тестовые задания ( ест-но не такие что требуют недели работы) по направлению будущей деятельности.
                      2. Кандидат решает задания, возможно несколькими способами.
                      3. Обсуждение решения (возможно даже удаленно) и разговор по душам технологиям.
                      Из плюсов:
                      Когда начинаются задачи на собеседовании, то всяко не хватает времени.
                      Можно решить задачу, но неоптимально или не тем способом который хотел увидеть собеседующий.
                      Кандидат оценит свой уровень относительно задач и может сразу отложит «поступление» — экономия времени у обоих сторон.
                      Если задачи решены, но не тем путем как ожидалось, то есть отличная «тема для беседы» на собеседовании.
                        0
                        Пункт 1 вполне заменяется гитхабом, если он наполнен.
                          0
                          Пункт 1 вполне заменяется гитхабом, если он наполнен.
                          Если «наполнение гитхаба» совпадает с «направлением будущей деятельности», то это конечно был бы идеальный вариант.

                          ЗЫ На SQL.RU периодически появляются вакансии, где вместо резюме можно указать ник на сайте.
                      0
                      А вот это как раз плохой паттерн. Из серии «если мы не поняли как человек думает, давайте, хотя бы, посмотрим как пишет». Если честно — стараюсь его применять только в тех случаях, когда не могу принять решение по результатам собеседования. И на то есть очень простая причина: человека можно научить писать код, но практически невозможно научить думать. А что касается «я не хочу», то тут тоже все не просто… Если вы сейчас не готовы «чисто по приколу» порассуждать об абстрактных величинах и высоких материях из мира программирования, захотите ли вы сидеть по 9 часов на работе, принимать указания от руководства какой проблемой «вот прямо сейчас» нужно заниматься вопреки собственным хотелкам и так далее… Да, я не отрицаю, собеседование — стрес. Причем не малый. Но иногда что-то в этой жизни приходится делать через «нихачу», «нимагу» и «нибуду». И ваши хотелки никогда не будут идти на 100% параллельно требованиям работодателя.
                        0
                        Из серии «если мы не поняли как человек думает, давайте, хотя бы, посмотрим как пишет».

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

                        Если вы сейчас не готовы «чисто по приколу» порассуждать об абстрактных величинах и высоких материях из мира программирования, захотите ли вы сидеть по 9 часов на работе, принимать указания от руководства какой проблемой «вот прямо сейчас» нужно заниматься вопреки собственным хотелкам и так далее…

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

                        Но иногда что-то в этой жизни приходится делать через «нихачу», «нимагу» и «нибуду».

                        Полностью с вами согласен, но рассуждениями это не проверяется.

                        И ваши хотелки никогда не будут идти на 100% параллельно требованиям работодателя.

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

                          Да, возможно. Но я буду видеть что вы рассуждаете. Заметьте, уже весьма не плохая «абилка».
                          Я готов порассуждать над конкретной проблемой, которую надо решить. Но не грузите меня пожалуйста графами например, которые у абстрактного вас ни писать ни обходить не надо. Когда я занимался ГИС, то я за неделю быстро освоил все основные способы обхода без всяких проблем, по справочным материалам.

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

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

                          Опять же, как наемный сотрудник, уверяю Вас — 100% это утопия. Если работа Вас изначально устраивает на все 100 — Вы либо чего-то не знаете, либо Вас жестоко нае… обманули. Либо соглашаетесь на 90, либо ищете работу до конца времен. Да, и это Ваше право. Если Вы видите, что интервью тупое и безъидейное, вопросы только про люки, или на оборот, собеседник грузит насущными проблемами, не имеющими вменяемого решения — попрощайтесь и уходите. Это будет честно по отношению к работодателю. Ну не срослось. Если я вижу, что собеседнику откровенно лень, на лбу написано «в гробу я эти графы видал» — я прерву интервью и попрощаюсь. И это тоже будет честно. Ровно так же «не срослось».
                            0
                            Внимательно прочитал и не увидел повода для спора. Мы с вами о разных вещах. Я говорю о собеседованиях, состоящем из 2-3 ключевых вопросов на порассуждаем. Вы говорите о собеседованиях, где порассуждаем — некоторая дополнительная бонусная часть. В таких случаях всё в порядке.
                          0
                          Тут скорее вопрос, что если интервьюер этот стрес нарочито усугубляет без видимой причины, то это лишний повод бежать, потому что в реальной работе этого «через нихачу, нимагу и нибуду» может тоже оказаться больше адекватного уровня
                          Люди бывают разные, задача интервьюера — именно раскрыть кандидата, а не сломать, многие этого не понимают
                          Иногда человек закрылся, стушевался (ну не умеет он проходить собеседования, бывает), а на деле оказывается шикарный специалист, именно то, что нужно
                          Иногда немного ошибаешься и ломаешь хорошего кандидата, у него остается ужасное впечатление от интервью, и ты его теряешь
                        +1
                        Почему-то большая часть программистов (мнение сложилось как раз по результатам чтения комментариев на Хабре) считают что техническое собеседование — бесполезная трата времени.
                        Техническое собеседование — это хорошо, если это именно собеседование. И как раз в таком контексте.
                        И, вы не поверите, мне хочется чтобы меня понимали! И мне нужно оценить, КАК БЫСТРО разработчик начнет понимать меня, если даже вообще ничего не понял сейчас.

                        ===================================
                        Плюс, отвечая на вопросы про люки, вы демонстрируете как умеете излагать свои мысли. Ответ по википедии/доке — малоинтересен. Куда больше интересны рассуждения с выходом на решение. Но это скорее уже не про тупые вопросы, а про тупые задачи.
                        Вопросы «про люки» я как встречал на нетехническом собеседовании. Были заданы «крутые вопросы, как гугле» и результат сверялся с какой-то шпаргалкой, там явно было написано что-то вроде
                        1 вопрос: люки — от 10423 до 11813
                        2 вопрос: тенисные шары — от 189338 до 197415
                        С таким же успехом можно было задавать по толкованию гороскопа из космополитен.
                          0
                          Основная проблема как раз в том, что «вопросы как в Гугле» уже давно известны всем и выучены на изусть вместе с ответами. И беда как раз в том, что их любят пихать именно нифига совсем не технические специалисты. Поскольку стильно-модно-молодежно. Возможно, имеет смысл их использовать в качестве повода для диалога, но никак не в качестве его основной темы.
                      0
                      Вы изучили не стек на профессиональном уровне, а как профессионально по нему проходить собеседования.


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

                      Проблема несколько в другом. Дело в том, что текущий объём используемых технологий в повседневной работе достаточно большой. Настолько большой, что приходится очень часто прибегать к разного рода справочникам (stackoverflow, zeal, wikipedia). А на собеседовании обычно ситуация выворачивается так, что только кандидат тупой, потому что до сих пор не запомнил всё это.


                      Бесспорно, я думаю проблема и в том и в том и еще в чем-то о чем мы с вами не знаем.

                      Всё у вас в кучу. Будущее проекта зависит в основном от умения его протолкнуть, а не правильности стека технологий. А выгорание сотрудника зависит от совокупности факторов, большая часть из которых связана с организацией труда, а не от того, есть ли на проекте jQuery.


                      Статья посвящена аспекту разработки проектов и квалификации сотрудника, а не их маркетинга и других сфер. Нам бы в рамках этой статьи с одной маленькой сферой разобраться. Так что в кучу все не у меня ;)
                        +1
                        Уверен, мои знания вы вряд ли можете оценить по имеющимся у вас данным.

                        Я не сказал, что у вас плохие знания.
                        Статья посвящена аспекту разработки проектов и квалификации сотрудника, а не их маркетинга и других сфер

                        Ваш же текст:
                        Будущее проектов, разрабатываемых с таким, пусть по незнанию, но безответственным подходом, прозаично и непродолжительно: существенные потери времени на ровном месте, сбои, финансовые и репутационные потери

                        Я вижу здесь другие сферы.
                      +1
                      Стараясь избегать этого стресса и лишних движений вообще, мы дистанцируемся не только от громогласного разоблачения нашего незнания некоторых базовых особенностей языка, но и от того, чтобы это незнание хоть немногоу меньшить.

                      Очень афористично! Хоть в дневник записывай.

                        +2
                        Прикладной код с использованием фреймворков и библиотек, который они привыкли писать каждый день, не может считаться надежным, если они пишем его без достаточного понимания разных аспектов его выполнения. Хорошей иллюстрацией этому из мира JavaScript служит судьба библиотеки JQuery, которая когда-то была двигателем прогресса а сегодня, будучи самозамкнутой областью знания, оторванной от всего остального языка, занимает свое естественное место на рынке — полупрофессиональные наспех написанные и работающие как придется скрипты в подарок к такой же быстрой верстке на бутстрапе от недорогих фрилансеров.

                        Для меня верно и обратное — слишком увлекаться деталями тоже не надо, а то закопаешься и вообще ничего не сделаешь. Главное это решить поставленную задачу так, как это устроит заказчика. Понимание всех аспектов придет с опытом. Матерыми специалистами не выпускаются из учебных заведений, не становятся, прочитав правильную книгу или статью, только опыт, только шишки. Про книги и спеки, безусловно, не стоит забывать, но практика имеет приоритет.
                          0
                          Согласен, вы описали довольно насущную для меня проблематику углубления в детали.
                          0
                          А как вы набираетесь фундаментальных знаний, andreiselin?
                            0
                            Пишу свои проекты. Будучи заинтересованным в их стабильной работе, я чувствую где слабое место и стараюсь обработать его с пониманием
                            +1
                            Ну а методы-то очевидны: всякие @deprecated и ворнинги (а потом и ошибки) компилятора. И вжух — уже все в курсе, что что-то поменялось.

                            Вы зря упомянули JS, потому что с JS случай довольно нестандартный: во имя обратной совместимости на JS в 2019 году можно писать всё так же, как и в каменном веке. И именно поэтому стандартные меры вроде контролируемых поломок обратной совместимости — в JS отсутствуют как класс, и тащить программистов к новым фичам можно только морковкой спереди (а не сзади).
                              0
                              Если вы не беретесь за первую попавшуюся работу, рассчитываете на нормальную зарплату и держите себя в тренде, у вас уже давно есть npm, webpack и typescript
                              То же касается современных актуальных проектов
                              А еще уже очень давно есть ES5 и «use strict», так что про совместимость тоже не вполне верно
                              Короче говоря, ваш комментарий был бы актуален 5 лет назад, но не сегодня, сегодня это может быть правдой только для очень заскорузлых разработчиков и жутчайшего легаси

                            Only users with full accounts can post comments. Log in, please.