Комментарии 36
Это, вкупе с ~20 собеседованиями, которые я провел сам в качестве нанимателя — достаточное число, чтобы стать королем собеседований сделать следующее наблюдение (изначально совершенно неочевидное) и утвердиться в нем: я убежден, что во многом благодаря такому количеству собеседований, начинающему походить на маргинальную привычку, я изучил свой стэк на профессиональном уровне и стал конкурентоспособным специалистом при том, что до этого уже работал 10 лет в веб-разработке.
Вы изучили не стек на профессиональном уровне, а как профессионально по нему проходить собеседования.
Любой разработчик, которому пришлось поработать на нескольких местах, подтвердит, что фундаментальные или творческие задачи, ставящиеся на интервью, редко имеют отношение к тому, с чем программист имеет дело в реальной жизни — никаких тебе рекурсий, графов и асинхронных систем управления лифтами на планете с отрицательной гравитацией в другом рукаве галактики.
Проблема несколько в другом. Дело в том, что текущий объём используемых технологий в повседневной работе достаточно большой. Настолько большой, что приходится очень часто прибегать к разного рода справочникам (stackoverflow, zeal, wikipedia). А на собеседовании обычно ситуация выворачивается так, что только кандидат тупой, потому что до сих пор не запомнил всё это.
Будущее проектов, разрабатываемых с таким, пусть по незнанию, но безответственным подходом, прозаично и непродолжительно: существенные потери времени на ровном месте, сбои, финансовые и репутационные потери и, как следствие, снижение энтузиазма к продолжению сотрудничества.
Всё у вас в кучу. Будущее проекта зависит в основном от умения его протолкнуть, а не правильности стека технологий. А выгорание сотрудника зависит от совокупности факторов, большая часть из которых связана с организацией труда, а не от того, есть ли на проекте jQuery.
А на собеседовании обычно ситуация выворачивается так, что только кандидат тупой, потому что до сих пор не запомнил всё это.Лучше и не скажешь.
Такая ситуация говорит только об одном: интевьюер неопытный или слишком самовлюбленный. Бегите. Если же вы не отвечаете на вопрос, а он спокойно переходит к следующему (возможно ответив на него самостоятельно) — скорее всего Вам повезло. Взвешиваться будет не результат ответа на 1 вопрос, а по совокупности.
Почему-то большая часть программистов (мнение сложилось как раз по результатам чтения комментариев на Хабре) считают что техническое собеседование — бесполезная трата времени. Это не так. Вашему потенциальному работодателю нужно оценить Ваш уровень знаний. Да, 90% этих знаний нормальный программист использует не осознанно, но в этом случае будет оцениваться именно наличие тех 10%. Все просто, если вы не можете ответить ни на 1 из 30 поставленных вопросов уровня «что такое рекурсия?», должен возникнуть вопрос, а работали ли вы разработчиком вообще те 10 лет, заявленные у вас в резюме? И, если таки работали, то что вообще отложилось у вас в голове?
Плюс, отвечая на вопросы про люки, вы демонстрируете как умеете излагать свои мысли. Ответ по википедии/доке — малоинтересен. Куда больше интересны рассуждения с выходом на решение. Но это скорее уже не про тупые вопросы, а про тупые задачи.
И да, я спрашиваю, например, про паттерны. И нет, это интересно не чисто в академическом срезе, поскольку постановка задачи может выглядеть как «вот к этому и вон тем объектам сделай общий фасад, а вот эти вот дурацкие состояния вообще убери нафиг и напиши нормальный обзервер!». И, вы не поверите, мне хочется чтобы меня понимали! И мне нужно оценить, КАК БЫСТРО разработчик начнет понимать меня, если даже вообще ничего не понял сейчас.
Почему-то большая часть программистов (мнение сложилось как раз по результатам чтения комментариев на Хабре) считают что техническое собеседование — бесполезная трата времени. Это не так. Вашему потенциальному работодателю нужно оценить Ваш уровень знаний. Да, 90% этих знаний нормальный программист использует не осознанно, но в этом случае будет оцениваться именно наличие тех 10%. Все просто, если вы не можете ответить ни на 1 из 30 поставленных вопросов уровня «что такое рекурсия?», должен возникнуть вопрос, а работали ли вы разработчиком вообще те 10 лет, заявленные у вас в резюме? И, если таки работали, то что вообще отложилось у вас в голове?
Плюс, отвечая на вопросы про люки, вы демонстрируете как умеете излагать свои мысли. Ответ по википедии/доке — малоинтересен. Куда больше интересны рассуждения с выходом на решение. Но это скорее уже не про тупые вопросы, а про тупые задачи.
И да, я спрашиваю, например, про паттерны. И нет, это интересно не чисто в академическом срезе, поскольку постановка задачи может выглядеть как «вот к этому и вон тем объектам сделай общий фасад, а вот эти вот дурацкие состояния вообще убери нафиг и напиши нормальный обзервер!». И, вы не поверите, мне хочется чтобы меня понимали! И мне нужно оценить, КАК БЫСТРО разработчик начнет понимать меня, если даже вообще ничего не понял сейчас.
Куда больше интересны рассуждения с выходом на решение. Но это скорее уже не про тупые вопросы, а про тупые задачи.
А я не хочу публично про себя рассуждать. Я тогда ощущаю себя сумасшедшим. И не хочу делать это в рамках интервью. Я готов подумать над проблемой по догоре домой и напишу аргументированный ответ. Но такую возможность мне не дают.
С одной стороны было бы удобно, с другой у работодателя не будет уверенности а ваш ли это ответ.
Для этого есть испытательный срок.
Который в случае неудачи невыгоден ни работодателю ни работнику. Иначе бы сразу всех желающих на него принимали.
Это проблема непонимания работодателем правильных подходов к испытательному сроку. Как все делают: садят человека на 2-3 месяца, а потом в конце думают надо или нет. Введение сотрудника в проект должно быть таким, чтобы уже через 2-3 недели было понятно нужен он или нет.
Ну и потом я не отрицаю собеседование как класс, я просто говорю, что публичные рассуждения на собеседовании это не всегда для меня. В в вопросах, которые сильно завязаны на стек технологий, можно порассуждать. А в вопросах как лучше обойти граф, ну извините.
Ну и потом я не отрицаю собеседование как класс, я просто говорю, что публичные рассуждения на собеседовании это не всегда для меня. В в вопросах, которые сильно завязаны на стек технологий, можно порассуждать. А в вопросах как лучше обойти граф, ну извините.
Ну во первых 2-3 недели это в любом случае потеря значительной суммы, а так же потеря времени. А потом со следующим так же. И еще с одним. В итоге наняли на пол года позже и все это время платили за испытательное.
Ну а параллельное прохождение испытательного многими людьми лучше по срокам, но гораздо хуже по деньгам. Помещение, рабочие места, время специалистов которых будут разрывать новички.
Работнику так же будет невыгодно увольняться с текущей работы если нет высокой уверенности что испытательный пройдет.
Ну а параллельное прохождение испытательного многими людьми лучше по срокам, но гораздо хуже по деньгам. Помещение, рабочие места, время специалистов которых будут разрывать новички.
Работнику так же будет невыгодно увольняться с текущей работы если нет высокой уверенности что испытательный пройдет.
Я не говорю, что нужно отменить собеседования. Можно побеседовать 2 часа и пощупать человека на предмет комфортно с ним будет работать или нет. Есть рекомендации. Есть неотвеченные вопросы, которые можно попросить ответить в письменной форме.
В совокупности всё вышеописанное уже неплохой источник информации для принятия решения.
Я говорю о том, что часто просят порассуждать о темах, связанных с программированием, но которые потом кодить не надо. и вот я против таких рассуждений, по крайней мере оперативных в рамках беседы.
Я предпочту тестовое задание, если уж хочется проверить как я думаю.
В совокупности всё вышеописанное уже неплохой источник информации для принятия решения.
Я говорю о том, что часто просят порассуждать о темах, связанных с программированием, но которые потом кодить не надо. и вот я против таких рассуждений, по крайней мере оперативных в рамках беседы.
Я предпочту тестовое задание, если уж хочется проверить как я думаю.
У вас очень специфический подход
90% моих коллег, включая меня, вообще против тестовых заданий и никогда их не делают
Поясню
Я довольно давно уже не джуниор и, если меняю работу, то тоже расчитываю на позицию архитектора/лида
Меня бессмысленно спрашивать рекурсии и просить написать шаблон приложения — это только покажет некомпетентность интервьюера
Мое резюме всегда в открытом доступе и я всегда в поиске
У меня нет времени на то, чтобы каждому потенциальному варианту посвящать часы на тестовое задание
С другой стороны, я могу рассказать что я думаю о правильной архитектуре приложения и паттернах разработки за пятнадцать минут
И да, если ваше собеседование длится 2 часа — от вас я тоже убегу
90% моих коллег, включая меня, вообще против тестовых заданий и никогда их не делают
Поясню
Я довольно давно уже не джуниор и, если меняю работу, то тоже расчитываю на позицию архитектора/лида
Меня бессмысленно спрашивать рекурсии и просить написать шаблон приложения — это только покажет некомпетентность интервьюера
Мое резюме всегда в открытом доступе и я всегда в поиске
У меня нет времени на то, чтобы каждому потенциальному варианту посвящать часы на тестовое задание
С другой стороны, я могу рассказать что я думаю о правильной архитектуре приложения и паттернах разработки за пятнадцать минут
И да, если ваше собеседование длится 2 часа — от вас я тоже убегу
90% моих коллег, включая меня, вообще против тестовых заданий и никогда их не делают
Если вы (чисто для примера) сидите на PHP 10 лет, то тестовые делать глупо. Но как только вы захотите радикально поменять стек, например геймдев на Си++, то и ЗП придётся попросить поменьше и тестовых поделать. Так что тут зависит от ситуации.
И да, если ваше собеседование длится 2 часа — от вас я тоже убегу
Собеседование — не пытка. Если реченька льётся, то нет смысла её останавливать. Если идёт с трудом, то можно и за 30 мин завершить.
Но как только вы захотите радикально поменять стекОбычно люди не меняют стек настолько радикально
Даже перейти с PHP на C# или .Net Core — нормально, но ваш пример какой-то категорически искусственный и попахивает дауншифтингом
Собеседование — не пыткаНе пытка, но испытание
Есть вполне четкие стандарты, обусловленные человеческой психологией и эффективностью самого процесса
Продолжительность нормального TI у подготовленного интервьюера — около 45 минут, максимум — час, если вы выходите за эти рамки, то, почти всегда, это значит, что интервьюер вы не очень или сами не знаете чего хотите
Дело тут все в том, что есть распространенная ошибка интервьюеров: они пытаются выявить уровень энциклопедических знаний у кандидата во всех смежных областях
Реально, если вы сами специалист в обсуждаемой сфере, вам бывает достаточно задать 3-5 вопросов чтобы оценить общий уровень кандидата, как практического специалиста и еще примерно столько же, чтобы понять подходит ли он для проекта и команды
Обычно люди не меняют стек настолько радикально
Меняют, это вообще лично мой пример. И среди моих знакомых я не одинок. Даже Go после Perl потребует уступить в ЗП и тщательной проверки кандидата. Мало ли он свой перл стиль будет в Go вставлять, а обычно так и происходит.
Даже перейти с PHP на C# или .Net Core — нормально, но ваш пример какой-то категорически искусственный и попахивает дауншифтингом
Вам то перейти может и нормально, а вот принимающая команда будет смотреть на вас косо. Нет боевого опыта на C# в год хотябы? Значит на кончиках пальцев нет чувства нюансов.
Это реальная ситуация. Дауншифтинг тут может и есть, но он вынужденный, чтобы потом расти дальше.
Реально, если вы сами специалист в обсуждаемой сфере, вам бывает достаточно задать 3-5 вопросов чтобы оценить общий уровень кандидата, как практического специалиста и еще примерно столько же, чтобы понять подходит ли он для проекта и команды
Кандидат может быть скрытым мудаком, который в первый день открытия кода скажет, что вы все тут мудаки и надо всё переписать. В 3-5 вопросов это можно не выяснить.
Обычно люди не меняют стек настолько радикально
Свалил с 1с на андроид. Не исключено что когда нибудь уйду в бекенд (а андроид все же фронт). А может и вовсе таки соберусь, подтяну математику со статистикой и пойду в какой нибудь анализ данных.
Да даже в мобилках когда/если буду менять андроид на флаттер таки на слово не поверят что во флаттере шарю.
К сожалению, бывают случаи, когда разработчик только через 1.5-2 месяца начинает выдавать первый код. Это совсем не проблема разработчика (про бюрократию в крупных компаниях слышали?), но на собеседовании при этом приходится принимать практически финальное решение.
Я готов подумать над проблемой по дороге домой и напишу аргументированный ответ.
С одной стороны было бы удобно, с другой у работодателя не будет уверенности а ваш ли это ответ.Эту проблему уже давно решили преподаватели ВУЗов — «Решил? Теперь расскажи ход решения!»
Человек на собеседовании может «не раскрыться» в силу разных обстоятельств.
Идеальное техническое собеседование, на мой взгляд, выглядит так.
1. Даются тестовые задания ( ест-но не такие что требуют недели работы) по направлению будущей деятельности.
2. Кандидат решает задания, возможно несколькими способами.
3. Обсуждение решения (возможно даже удаленно) и разговор по
Из плюсов:
Когда начинаются задачи на собеседовании, то всяко не хватает времени.
Можно решить задачу, но неоптимально или не тем способом который хотел увидеть собеседующий.
Кандидат оценит свой уровень относительно задач и может сразу отложит «поступление» — экономия времени у обоих сторон.
Если задачи решены, но не тем путем как ожидалось, то есть отличная «тема для беседы» на собеседовании.
А вот это как раз плохой паттерн. Из серии «если мы не поняли как человек думает, давайте, хотя бы, посмотрим как пишет». Если честно — стараюсь его применять только в тех случаях, когда не могу принять решение по результатам собеседования. И на то есть очень простая причина: человека можно научить писать код, но практически невозможно научить думать. А что касается «я не хочу», то тут тоже все не просто… Если вы сейчас не готовы «чисто по приколу» порассуждать об абстрактных величинах и высоких материях из мира программирования, захотите ли вы сидеть по 9 часов на работе, принимать указания от руководства какой проблемой «вот прямо сейчас» нужно заниматься вопреки собственным хотелкам и так далее… Да, я не отрицаю, собеседование — стрес. Причем не малый. Но иногда что-то в этой жизни приходится делать через «нихачу», «нимагу» и «нибуду». И ваши хотелки никогда не будут идти на 100% параллельно требованиям работодателя.
Из серии «если мы не поняли как человек думает, давайте, хотя бы, посмотрим как пишет».
Если я буду рассуждать, а вы что-то там обо мне поймёте, то это иллюзия.
Если вы сейчас не готовы «чисто по приколу» порассуждать об абстрактных величинах и высоких материях из мира программирования, захотите ли вы сидеть по 9 часов на работе, принимать указания от руководства какой проблемой «вот прямо сейчас» нужно заниматься вопреки собственным хотелкам и так далее…
Я готов порассуждать над конкретной проблемой, которую надо решить. Но не грузите меня пожалуйста графами например, которые у абстрактного вас ни писать ни обходить не надо. Когда я занимался ГИС, то я за неделю быстро освоил все основные способы обхода без всяких проблем, по справочным материалам.
Но иногда что-то в этой жизни приходится делать через «нихачу», «нимагу» и «нибуду».
Полностью с вами согласен, но рассуждениями это не проверяется.
И ваши хотелки никогда не будут идти на 100% параллельно требованиям работодателя.
Я поищу другого, благо сейчас работы больше, чем работников её ищущих.
Давайте попробую уточнить: Вы сейчас смотрите на собеседование как потенциальный сотрудник, а я как потенциальный работодатель, при том что сам являюсь наемным сотрудником. Однако, мой личный профит очень сильно зависит от того, кого я беру на работу. Оставим это как основной постулат…
Да, возможно. Но я буду видеть что вы рассуждаете. Заметьте, уже весьма не плохая «абилка».
Хотя я очень внимательно читаю резюме сотрудников перед собеседованием, далеко не всегда там написано «досканально знаком со способами построения и обхода графов». И если там этого нет — вопрос на «общий уровень развития» считаю вполне уместным, если других вопросов не осталось. Кандидат хотябы читает Хабр, знает список «тупых» вопросов и не поленился загуглить ответы. Конкретно в Вашем же случае — это скорее плюс. Блеснуть знаниями на знакомой теме. В чем проблема? И обратная ситуация: если кандидат про методы обхода графов слышит первый раз, это не повод для отказа. Именно потому, что это учится за неделю. Может он при это SQL-запросы пишет божественно?
Опять же, как наемный сотрудник, уверяю Вас — 100% это утопия. Если работа Вас изначально устраивает на все 100 — Вы либо чего-то не знаете, либо Вас жестоконае… обманули. Либо соглашаетесь на 90, либо ищете работу до конца времен. Да, и это Ваше право. Если Вы видите, что интервью тупое и безъидейное, вопросы только про люки, или на оборот, собеседник грузит насущными проблемами, не имеющими вменяемого решения — попрощайтесь и уходите. Это будет честно по отношению к работодателю. Ну не срослось. Если я вижу, что собеседнику откровенно лень, на лбу написано «в гробу я эти графы видал» — я прерву интервью и попрощаюсь. И это тоже будет честно. Ровно так же «не срослось».
Если я буду рассуждать, а вы что-то там обо мне поймёте, то это иллюзия.
Да, возможно. Но я буду видеть что вы рассуждаете. Заметьте, уже весьма не плохая «абилка».
Я готов порассуждать над конкретной проблемой, которую надо решить. Но не грузите меня пожалуйста графами например, которые у абстрактного вас ни писать ни обходить не надо. Когда я занимался ГИС, то я за неделю быстро освоил все основные способы обхода без всяких проблем, по справочным материалам.
Хотя я очень внимательно читаю резюме сотрудников перед собеседованием, далеко не всегда там написано «досканально знаком со способами построения и обхода графов». И если там этого нет — вопрос на «общий уровень развития» считаю вполне уместным, если других вопросов не осталось. Кандидат хотябы читает Хабр, знает список «тупых» вопросов и не поленился загуглить ответы. Конкретно в Вашем же случае — это скорее плюс. Блеснуть знаниями на знакомой теме. В чем проблема? И обратная ситуация: если кандидат про методы обхода графов слышит первый раз, это не повод для отказа. Именно потому, что это учится за неделю. Может он при это SQL-запросы пишет божественно?
Полностью с вами согласен, но рассуждениями это не проверяется.
Я поищу другого, благо сейчас работы больше, чем работников её ищущих.
Опять же, как наемный сотрудник, уверяю Вас — 100% это утопия. Если работа Вас изначально устраивает на все 100 — Вы либо чего-то не знаете, либо Вас жестоко
Тут скорее вопрос, что если интервьюер этот стрес нарочито усугубляет без видимой причины, то это лишний повод бежать, потому что в реальной работе этого «через нихачу, нимагу и нибуду» может тоже оказаться больше адекватного уровня
Люди бывают разные, задача интервьюера — именно раскрыть кандидата, а не сломать, многие этого не понимают
Иногда человек закрылся, стушевался (ну не умеет он проходить собеседования, бывает), а на деле оказывается шикарный специалист, именно то, что нужно
Иногда немного ошибаешься и ломаешь хорошего кандидата, у него остается ужасное впечатление от интервью, и ты его теряешь
Люди бывают разные, задача интервьюера — именно раскрыть кандидата, а не сломать, многие этого не понимают
Иногда человек закрылся, стушевался (ну не умеет он проходить собеседования, бывает), а на деле оказывается шикарный специалист, именно то, что нужно
Иногда немного ошибаешься и ломаешь хорошего кандидата, у него остается ужасное впечатление от интервью, и ты его теряешь
Почему-то большая часть программистов (мнение сложилось как раз по результатам чтения комментариев на Хабре) считают что техническое собеседование — бесполезная трата времени.Техническое собеседование — это хорошо, если это именно собеседование. И как раз в таком контексте.
И, вы не поверите, мне хочется чтобы меня понимали! И мне нужно оценить, КАК БЫСТРО разработчик начнет понимать меня, если даже вообще ничего не понял сейчас.
===================================
Плюс, отвечая на вопросы про люки, вы демонстрируете как умеете излагать свои мысли. Ответ по википедии/доке — малоинтересен. Куда больше интересны рассуждения с выходом на решение. Но это скорее уже не про тупые вопросы, а про тупые задачи.Вопросы «про люки» я как встречал на нетехническом собеседовании. Были заданы «крутые вопросы, как гугле» и результат сверялся с какой-то шпаргалкой, там явно было написано что-то вроде
1 вопрос: люки — от 10423 до 11813
2 вопрос: тенисные шары — от 189338 до 197415
С таким же успехом можно было задавать по толкованию гороскопа из космополитен.
Основная проблема как раз в том, что «вопросы как в Гугле» уже давно известны всем и выучены на изусть вместе с ответами. И беда как раз в том, что их любят пихать именно нифига совсем не технические специалисты. Поскольку стильно-модно-молодежно. Возможно, имеет смысл их использовать в качестве повода для диалога, но никак не в качестве его основной темы.
Вы изучили не стек на профессиональном уровне, а как профессионально по нему проходить собеседования.
Эта мысль отражена в статье, но спасибо что сделали ее еще более явной.
Уверен, мои знания вы вряд ли можете оценить по имеющимся у вас данным.
Проблема несколько в другом. Дело в том, что текущий объём используемых технологий в повседневной работе достаточно большой. Настолько большой, что приходится очень часто прибегать к разного рода справочникам (stackoverflow, zeal, wikipedia). А на собеседовании обычно ситуация выворачивается так, что только кандидат тупой, потому что до сих пор не запомнил всё это.
Бесспорно, я думаю проблема и в том и в том и еще в чем-то о чем мы с вами не знаем.
Всё у вас в кучу. Будущее проекта зависит в основном от умения его протолкнуть, а не правильности стека технологий. А выгорание сотрудника зависит от совокупности факторов, большая часть из которых связана с организацией труда, а не от того, есть ли на проекте jQuery.
Статья посвящена аспекту разработки проектов и квалификации сотрудника, а не их маркетинга и других сфер. Нам бы в рамках этой статьи с одной маленькой сферой разобраться. Так что в кучу все не у меня ;)
Уверен, мои знания вы вряд ли можете оценить по имеющимся у вас данным.
Я не сказал, что у вас плохие знания.
Статья посвящена аспекту разработки проектов и квалификации сотрудника, а не их маркетинга и других сфер
Ваш же текст:
Будущее проектов, разрабатываемых с таким, пусть по незнанию, но безответственным подходом, прозаично и непродолжительно: существенные потери времени на ровном месте, сбои, финансовые и репутационные потери
Я вижу здесь другие сферы.
Стараясь избегать этого стресса и лишних движений вообще, мы дистанцируемся не только от громогласного разоблачения нашего незнания некоторых базовых особенностей языка, но и от того, чтобы это незнание хоть немногоу меньшить.
Очень афористично! Хоть в дневник записывай.
Прикладной код с использованием фреймворков и библиотек, который они привыкли писать каждый день, не может считаться надежным, если они пишем его без достаточного понимания разных аспектов его выполнения. Хорошей иллюстрацией этому из мира JavaScript служит судьба библиотеки JQuery, которая когда-то была двигателем прогресса а сегодня, будучи самозамкнутой областью знания, оторванной от всего остального языка, занимает свое естественное место на рынке — полупрофессиональные наспех написанные и работающие как придется скрипты в подарок к такой же быстрой верстке на бутстрапе от недорогих фрилансеров.
Для меня верно и обратное — слишком увлекаться деталями тоже не надо, а то закопаешься и вообще ничего не сделаешь. Главное это решить поставленную задачу так, как это устроит заказчика. Понимание всех аспектов придет с опытом. Матерыми специалистами не выпускаются из учебных заведений, не становятся, прочитав правильную книгу или статью, только опыт, только шишки. Про книги и спеки, безусловно, не стоит забывать, но практика имеет приоритет.
А как вы набираетесь фундаментальных знаний, andreiselin?
Ну а методы-то очевидны: всякие @deprecated и ворнинги (а потом и ошибки) компилятора. И вжух — уже все в курсе, что что-то поменялось.
Вы зря упомянули JS, потому что с JS случай довольно нестандартный: во имя обратной совместимости на JS в 2019 году можно писать всё так же, как и в каменном веке. И именно поэтому стандартные меры вроде контролируемых поломок обратной совместимости — в JS отсутствуют как класс, и тащить программистов к новым фичам можно только морковкой спереди (а не сзади).
Вы зря упомянули JS, потому что с JS случай довольно нестандартный: во имя обратной совместимости на JS в 2019 году можно писать всё так же, как и в каменном веке. И именно поэтому стандартные меры вроде контролируемых поломок обратной совместимости — в JS отсутствуют как класс, и тащить программистов к новым фичам можно только морковкой спереди (а не сзади).
Если вы не беретесь за первую попавшуюся работу, рассчитываете на нормальную зарплату и держите себя в тренде, у вас уже давно есть npm, webpack и typescript
То же касается современных актуальных проектов
А еще уже очень давно есть ES5 и «use strict», так что про совместимость тоже не вполне верно
Короче говоря, ваш комментарий был бы актуален 5 лет назад, но не сегодня, сегодня это может быть правдой только для очень заскорузлых разработчиков и жутчайшего легаси
То же касается современных актуальных проектов
А еще уже очень давно есть ES5 и «use strict», так что про совместимость тоже не вполне верно
Короче говоря, ваш комментарий был бы актуален 5 лет назад, но не сегодня, сегодня это может быть правдой только для очень заскорузлых разработчиков и жутчайшего легаси
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О роли тестовых заданий в жизни разработчика