Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 94
Чтобы избежать недоразумений — эта статья является очень вольным «переводом» статьи из моего блога.
Спасибо, что перевели, лень было всё читать на английском 4-5 дней назад. Хотя идея была понятна.
Замечу, что такие тестовые задания не тратят много времени разработчика (основной ресурс) и показывают его реальный уровень. Если собеседуемый не мотивирован или неспособен выполнить, он просто не сделает его. И все получают то, что им надо.
Как вариант, нужно посмотреть знания разработчика в нормальных условиях программирования, но тогда такое задание растягивается на 6-8 часов, а у работодателя сохраняются вопросы, один ли соискатель его дома делал. (Что легко пронять по наводящим вопросам, но это всё искусство интервьюера.)
Замечу, что такие тестовые задания не тратят много времени разработчика (основной ресурс) и показывают его реальный уровень. Если собеседуемый не мотивирован или неспособен выполнить, он просто не сделает его. И все получают то, что им надо.
Как вариант, нужно посмотреть знания разработчика в нормальных условиях программирования, но тогда такое задание растягивается на 6-8 часов, а у работодателя сохраняются вопросы, один ли соискатель его дома делал. (Что легко пронять по наводящим вопросам, но это всё искусство интервьюера.)
Похоже некоторые работодатели так и не понимают, что в большинстве случаев с тестовым заданием можно нанять только достаточно среднего разработчика. Потому что человек, знающий себе цену — не будет тратить 6-8 часов дома на выполнение теста, да и 3-4 часа на собеседование (+ дорога) вряд ли найдется в будний день. Конечно, если вы контора уровня Google, Microsoft, Apple, Facebook и т.д. — то вы можете себе такое позволить, но ООО «NoName и Ко» хороших разработчиков с такой стратегией не найдет.
Похоже некоторые работодатели так и не понимают, что в большинстве случаев с тестовым заданием можно нанять только достаточно среднего разработчика. Потому что человек, знающий себе цену
У вас выходит так, что средний разработчик по определению не может знать тот факт, что он на текущий момент в той конкретной области — средний разработчик.
Обоснуйте, не понял ваш посыл.
Ну вы противопоставляете понятия «достаточно средний разработчик» и «человек знающий себе цену». А их бессмысленно противопоставлять, один и тот же человек легко может попадать под обе категории или не входить в них.
Ок, да, несколько неточно выразился. Я имел ввиду что более-менее квалифицированные люди не пойдут к таким работодателям. Пойдут только те, кто находится в сегменте рынка труда, в котором предложение сильно превышает спрос. В основном это джуниоры и, может, частично middle разработчики.
Эффект Даннинга — Крюгера — когнитивное искажение, которое заключается в том, что люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации[1]. Это приводит к возникновению у них завышенных представлений о собственных способностях, в то время как действительно высококвалифицированные люди, наоборот, склонны занижать свои способности и страдать недостаточной уверенностью в своих силах, считая других более компетентными.
А что плохого в заданиях на двоичные деревья, в том числе на сортировку?
Ничего, это хорошие задания на знания теории и основ, но в реальных проектах писать такие вещи нужно всего в 5-10%, т.к. это все уже давно и по 10 раз реализовано в виде удобных и проверенных библиотек. Тратить время на их написание просто глупо. Поэтому и сотрудника лучше искать, который умеет делать то, что нужно будет для реальных проектов. Смотреть на то, как быстро он умеет учиться и выполнять поставленные задачи за отведенное время.
Задача на сортировку несколько однобока. Слишком теоретическая.
Лучше спрашивать логические задачки из той области на которой специализируется ваша компания.
Вот пример интересных на мой взгляд вопросов.
Например реализация скользящих окон при обработке интенсивного потока телеметрии — ТОП 100 угроз и прочее.
Случайная выборка данных из неравномерного потока с хорошим случайным распределением по всему потоку. Как вариант задачи выбрать 1000 действительно случайных строк из текстового файла проходясь по нему только один раз.
Построить «хитрую» структуру данных со сложностью доступа и манипуляции ими O(1). Яркий вариант LRU Cache, хотя эта задача уже 100 раз решена видел десятки решений со логарифмической сложностью.
Как удалить элемент из массива за O(1) — очень интересный вариант. Нельзя да… если не пренебречь чем-то. Вот тут сразу можно сказать много о человеке видя как он рассуждает.
И так далее…
Лучше спрашивать логические задачки из той области на которой специализируется ваша компания.
Вот пример интересных на мой взгляд вопросов.
Например реализация скользящих окон при обработке интенсивного потока телеметрии — ТОП 100 угроз и прочее.
Случайная выборка данных из неравномерного потока с хорошим случайным распределением по всему потоку. Как вариант задачи выбрать 1000 действительно случайных строк из текстового файла проходясь по нему только один раз.
Построить «хитрую» структуру данных со сложностью доступа и манипуляции ими O(1). Яркий вариант LRU Cache, хотя эта задача уже 100 раз решена видел десятки решений со логарифмической сложностью.
Как удалить элемент из массива за O(1) — очень интересный вариант. Нельзя да… если не пренебречь чем-то. Вот тут сразу можно сказать много о человеке видя как он рассуждает.
И так далее…
Интересно, что бы Вы ответили на вопрос из habrahabr.ru/company/roem/blog/214297/?
Для сортировки в javascript есть
[].sort(). Не могу с ходу придумать кейс чтобы пришлось писать свою сортировку.
А ее не надо писать самому. Надо знать, как оно работает и может работать в других случаях, что бы потом не было вопросов «а чего это оно так долго работает?» (сложность алгоритмов и все такое)
Да, желательно знать. Но по этому конкретно пункту я согласен с автором. Есть и поважнее вещи для фронтендера.
Пишите тесты, и не парьтесь со знанием как оно работает. Невозможно все знать, но если не лениться писать тесты, то можно делать качественные решения.
Невозможно всё знать, но если вы не отличаете O(N^2) от O(N), то ваши решения ну никак не могут быть качественными.
некачественный фронтэд в 90% случаев бывает из за плохого знания CSS, HTML, JavaScript, браузерных API, API популярных библиотек и только где-то в 10 очередь из за незнания теории сложности алгоритмов.
Я регулярно вижу как люди используют линейный поиск по массиву вместо поиска в хэш-таблице и это очень угарно.
Между тем, ваше утверждение очень забавно. Потому что само по себе его можно трактовать не как «знание теории сложности алгоритмов не так важно», а как «на фронтенде люди не могут пока что освоить JS, куда уж там теория сложности алгоритмов»
Между тем, ваше утверждение очень забавно. Потому что само по себе его можно трактовать не как «знание теории сложности алгоритмов не так важно», а как «на фронтенде люди не могут пока что освоить JS, куда уж там теория сложности алгоритмов»
И какая сложность у sort?
И какая у него сложность в среднем, лучшем и худшем случае?
Разные алгоритмы используются в разных браузерах. И в каждом может разный использоваться в зависимости от ситуации. Merge sort, Selection sort, Quicksort. Вообще стандарт языка не уточняет какой алгоритм должен использоваться.
Можете привести пример где знание сложности
Можете привести пример где знание сложности
[].sort() будет полезно программисту? Мне вот правда интересно, сам не могу придумать.
Банальный пример. Excel-подобный интерфейс в вебе. Чтобы все работало быстренько, данные кешируются на клиенте. Одна из функций таблицы — сортировка по столбцам. Тут потребуется знать даже больше чем то, как работает сортировка. Например, вам потребуется очень внимательно следить за структурами данных и вероятнее всего, использовать хэш-таблицы вместо массивов, чтобы обеспечить приемлимое быстродействие.
Сортировка integer? Не слишком экзотично? (:
>>>[11,1,2,3].sort()
[1, 11, 2, 3]
stackoverflow.com/questions/1063007/sort-not-working-with-integers
По дефолту сортируются как строки. Меня как рубиста это удивило в своё время.
>>>[11,1,2,3].sort()
[1, 11, 2, 3]
stackoverflow.com/questions/1063007/sort-not-working-with-integers
По дефолту сортируются как строки. Меня как рубиста это удивило в своё время.
Ничего в них плохого нет. Просто некоторые конторы хотят нанять сразу узких специалистов, а некоторые — людей пусть с худшим уровнем фундаментальных знаний, но зато готового «закрыть своей грудью брешь в команде».
Скажем у нас в команде, разрабатывающей кой-какие вещи, связанные с Андроидом недавно наняли человека вообще без знания Java и Python'а (на котором у нас система сборки написана). Ну не знает он их и не знает — через пару месяцев выучит. А вот если он нам куда-нибудь алгоритм со соростью O(N^2) вместо O(N) вкрутит (как кандидат, которого не взяли сделал прямо на интервью в совершенно игрушечной задаче) — то мы будем долго пытаться понять почему у нас все тесты (кроме, может быть, нагрузочных) проходят, а на боевой нагрузке всё ложится (хорошо если на нагрузочных тестах ещё, а не у заказчика).
И вот если у вас сроки горят и нужно выпустить хоть что-то хоть как-то работающее, то тестовое задание из статьи — то, что вам нужно.
Скажем у нас в команде, разрабатывающей кой-какие вещи, связанные с Андроидом недавно наняли человека вообще без знания Java и Python'а (на котором у нас система сборки написана). Ну не знает он их и не знает — через пару месяцев выучит. А вот если он нам куда-нибудь алгоритм со соростью O(N^2) вместо O(N) вкрутит (как кандидат, которого не взяли сделал прямо на интервью в совершенно игрушечной задаче) — то мы будем долго пытаться понять почему у нас все тесты (кроме, может быть, нагрузочных) проходят, а на боевой нагрузке всё ложится (хорошо если на нагрузочных тестах ещё, а не у заказчика).
И вот если у вас сроки горят и нужно выпустить хоть что-то хоть как-то работающее, то тестовое задание из статьи — то, что вам нужно.
А вместе с ростом популярности CoffeeScript и разнообразных библиотек и фреймворков они и вовсе теряют всякий смысл.
Это вы зря. Основы нужно знать всегда.
Поддерживаю. Это применимо ко всем ЯП. Устраиваясь работать в одну компанию — на их компе выполнял тестовое задание, реально работающее приложение с авторизацией, логами и т.д. + оформление + немного js. Времени на его выполнение было впритык, но каким-то чудом успел. Позже общаясь с лидом, который и проверял мое задание и множество других — узнал что смысл этого где-то такой же как вы и описали: посмотреть как человек работает в условиях нехватки времени, как он мыслит.
Если вы говорите, что фронтэнд разработчик не должен знать замыкания, прототипы — основы js, тогда это не фронтэнд разработчик, а верстальщик. Печально.
Я этого не говорил. Я написал, что это «требует изучения». Вы как-то между строк прочитали.
Т.е. «требует изучения» — это будет в рабочее время?
>поощряют всевозможные хаки, которые в реальной рабочей обстановке либо вообще не используются, либо гуглятся за минуту.
Именно что спец по JS должен это всё сразу знать. А не говнокодить свои велосипеды или сидеть в гугле из-за того что он не знал решения в пару строк.
Если вы про позицию Junior, то со статьёй можно согласиться, но тогда это надо было озвучить в статье.
>поощряют всевозможные хаки, которые в реальной рабочей обстановке либо вообще не используются, либо гуглятся за минуту.
Именно что спец по JS должен это всё сразу знать. А не говнокодить свои велосипеды или сидеть в гугле из-за того что он не знал решения в пару строк.
Если вы про позицию Junior, то со статьёй можно согласиться, но тогда это надо было озвучить в статье.
Каким образом конструкция split(‘’).reverse().join(‘’) может показать уровень разработчика? arguments на самом деле псевдомассив и надо применить Array.prototype.slice.call, чтобы сконвертировать его в нормальный массив? Ну дела. В чем разница между call() и apply()? Чёрт его знает, что-то там с массивом было. Сортировка с помощью двоичного дерева?
…
Вместо этого интервьюирующие тешат своё самолюбие и поощряют всевозможные хаки, которые в реальной рабочей обстановке либо вообще не используются, либо гуглятся за минуту.
Надеюсь, это всё сарказм? Иначе хороший же из вас разработчик.
Я вот сарказма не уловил. Видимо автор серьёзно, к сожалению.
Это полезные знания, я просто против возведения их в статус святой коровы.
На мой взгляд, вышеупомянутое тестовое задание проверку «основ» выполнило на ура. В то же время я бы наверняка запоролся на заданиях типа dmitry.baranovskiy.com/post/so-you-think-you-know-javascript
А можно для тех, кто на js пишет иногда и непрофессионально, пояснить, что такое split(‘’).reverse().join(‘’)?
Это нигде не может понадобится, но если человек не может ответить на этот вопрос, то он будет долго пытаться понять что происходит в программе где вместо split('-') или split(' ') написали split('')
JavaScript — он же такой: все программы на нём, как известно необычайно надёжны (то есть тщательно от вас скрывают что всё уже слетело с катушек и пошло наперекосяк), потому вам в таких случаях ничего не поможет, кроме хорошего знания разложенных повсюду граблей.
JavaScript — он же такой: все программы на нём, как известно необычайно надёжны (то есть тщательно от вас скрывают что всё уже слетело с катушек и пошло наперекосяк), потому вам в таких случаях ничего не поможет, кроме хорошего знания разложенных повсюду граблей.
Спасибо. Я ожидал чего-то более контр-интуитивного, чем отсутствие метода reverse() у строк.
ответ на этот вопрос
Читая статьи на хабре, для себя заметил, что программисты делятся на тех кто пишет рабочий код и тех кто знает кучу крутых терминов, месяцами пишет правильный код. И вот черт его знает что лучше. Но за статью спасибо. Полностью согласен что тестовое задание должно быть реальным. На последей из работ дали доступ к проекту и сказали наваять кое-что, а там (ужос!) всё не знакомо и неизвестно, но не беда, чуток поглулил документацию от фреймфорка, посмотрел как сделал другой прогер аналогичную штуку в другой части и получил работу ^_^. Вот это норм, а не сортировка дерева на бумажке.
Вроде бы уже тысячу лет как известно, что хороший рецепт это: 1) пишем рабочий код, 2) делаем код правильным для дальнейшего масштабирования. Можно (и лучше) впихнуть на первое место тесты и делать все по ТДД, можно нет. Только правильный код пишут обычно молодые ребята, познакомившиеся с паттернами и рефакторингом, неизбежно скатываясь в оверинжиниринг. Только рабочий код, по-моему мнению, пишут какие-то говнари, в проект которых посторонним лучше не заглядывать вообще.
Нда, вот оно, новое поколение разработчиков :)
Согласен с тем, что стоит давать задание, близкое к боевому, в смысле без бессмысленных ограничений вроде «не использовать существующее API, пишем все обёртки с нуля», «не использовать if» и прочего шизоида.
Не согласен с тем, что стоит ставить такие жесткие сроки. Если в конторе это нормальная ситуация с задачами, то может ну нафиг такое место?
Не согласен с тем, что стоит ставить такие жесткие сроки. Если в конторе это нормальная ситуация с задачами, то может ну нафиг такое место?
Хочется попробовать что-то новое. И вообще я по себе заметил, что при нехватке времени моя продуктивность заметно повышается :)
Но вы всё равно бы не сдали заказчику результат за 2 часа, судя по тексту — была куча мест, которые «можно было бы сделать лучше», и не работало «переключение страниц».
Плюс, если в команде нормальная ситуация «сделай за 2 часа, пофиг на качество» — наверняка будут и «скоро дедлайн, работаем по 12 часов и без выходных, и конечно без доплаты, или тебе что, пофиг на судьбу проекта».
Опять же, что считать продкутивностью. Время запуска рабочего приложения? Время запуска рабочего не глючащего приложения? Время запуска работающего, не глючащего и не тормозящего приложения? Впрочем, если вы из тех, кто в стрессовой ситуации способен выдать лучший по качеству результат, чем в спокойной — я вам завидую. :-)
Ну и опять же, новое можно и без чужого пинка опробовать…
Плюс, если в команде нормальная ситуация «сделай за 2 часа, пофиг на качество» — наверняка будут и «скоро дедлайн, работаем по 12 часов и без выходных, и конечно без доплаты, или тебе что, пофиг на судьбу проекта».
Опять же, что считать продкутивностью. Время запуска рабочего приложения? Время запуска рабочего не глючащего приложения? Время запуска работающего, не глючащего и не тормозящего приложения? Впрочем, если вы из тех, кто в стрессовой ситуации способен выдать лучший по качеству результат, чем в спокойной — я вам завидую. :-)
Ну и опять же, новое можно и без чужого пинка опробовать…
Да я и пробую постоянно что-то новое вне работы, но всё-таки 8 часов в день не хочется проводить за однообразным рутинным трудом без возможности для роста. А именно так у меня последние полгода и выглядел рабочий день…
«сделай за 2 часа, пофиг на качество» — думаю в данном случае всё будет в порядке. Контора работает с крупными фирмами, есть много постоянных клиентов. Ну и ко всему прочему — это немцы :) Не думаю, что меня там будут нагло эксплуатировать и заставлять работать по принципу «тяп-ляп и в продакшн» :)
«сделай за 2 часа, пофиг на качество» — думаю в данном случае всё будет в порядке. Контора работает с крупными фирмами, есть много постоянных клиентов. Ну и ко всему прочему — это немцы :) Не думаю, что меня там будут нагло эксплуатировать и заставлять работать по принципу «тяп-ляп и в продакшн» :)
целью этого тестового задания было определить, как я буду работать в условиях жёсткой нехватки времени
И недолго придётся ждать, когда человек выгорит при перманентном аврале и превратится в тыкву. Ну, успеет, наверное, наколбасить парочку приложений, которые можно будет продать.
Всё же, на мой взгляд, какая-то странная жизненная философия в последнее время навязывается: «ты должен жить и работать в условиях жёсткой нехватки времени», потому что нам надо зарабатывать деньги.
На мой взгляд те, кто дает такие задания, не подразумевают работать потом в аврале. Они хотят посмотреть, как соображает программер в условиях, когда сделать все и сразу не получится изначально (примером может быть создание прототипа, когда команда собирается раз в день и смотрит, куда идти дальше, забивая на мелочи). Т.е. какую стратегию выполнения человек выбирает (в данном случае — вначале фичи, затем красивости), приоритет выполнения фич (когда незначительные для результата отодвигаются на потом), может ли кандидат делать step-by-step законченные фичи, и т.п.
Вообще мне такое задание сильно напоминает live coding без задачи сделать законченное решение. Просто чтобы интервьювер посмотрел как чел себя будет вести в реальной разработке.
Вообще мне такое задание сильно напоминает live coding без задачи сделать законченное решение. Просто чтобы интервьювер посмотрел как чел себя будет вести в реальной разработке.
Если люди, дающее такое задание, «не подразумевают работать потом в аврале» то вообще садизм и куда хуже даже тех самых сортировок с помощью двоичного дерева. Потому работа в цейтноте и работа «когда сделать все и сразу не получится изначально» — две очень большие разницы. А уж «работа в цейтноте без всякой обратной связи» — это и вообще не имеет никакого отношения к реальности: либо ваш заказчик понимает, что он требует невыполнимого и готов обсуждать компромиссы (а как вы без него решите что именно из требуемого нужно делать в первую голову если всё одновременно сделать нельзя?), либо это в чистом виде «перманентный аврал» когда ваша команда/компания «делает хорошую мину при плохой игре» и пытается заставить вас сделать за неделю то, что, по хорошему, требует полгода.
Такой пример: есть те же 2 часа Вашего рабочего времени. Ваш потенциальный работодатель хочет понять, что каждые 2 часа рабочего времени Вы будете решать задачи, а не тупить над элементарными вопросами типа «как назвать метод».
Ну и опять же — не факт, что подразумевается решать такое тестовое в авральном режиме. Надо просто покодить эти 2 часа ни на что не отвлекаясь, но и при этом ничего себе не порвав. ;)
Я конечно понимаю, что такие задания могут давать в контексте авралов и прочей ереси. Но я оптимист. :)
Ну и у меня был только описываемый опыт в режиме live coding.
Ну и опять же — не факт, что подразумевается решать такое тестовое в авральном режиме. Надо просто покодить эти 2 часа ни на что не отвлекаясь, но и при этом ничего себе не порвав. ;)
Я конечно понимаю, что такие задания могут давать в контексте авралов и прочей ереси. Но я оптимист. :)
Ну и у меня был только описываемый опыт в режиме live coding.
В ситуации с таким невыполнимым заданием стоит сразу спросить, что из этого нужно через два часа.
«Прототипы, Замыкания, Hoisting» всё же нужно знать фротнтеду, и знать хорошо. Это почти базовые вещи.
Складывалось впечатление, что тестовые задания специально не имеют ничего общего с тем, с чем javascript-разработчикам приходится ежедневно сталкиваться.
Если я правильно понял, что в тестовых заданиях были вопросы про «Прототипы, Замыкания, Hoisting», то это как раз то, с чем приходится сталкиваться ежедневно.
А каждый повар должен знать что NaCl производится и используется после промышленной очистки минерала Галит?
Я могу использовать приемы, но не знать что они оказываются называются, скажем «замыкания».
Я могу использовать приемы, но не знать что они оказываются называются, скажем «замыкания».
Если используете, но не знаете как называется, то ничего против не имею. Я сам такой. Просто в топике кажется про полное незнание.
Я действительно понятия не имел, как эта штука называется, пока не прочитал The Definitive Guide. В собственных проектах я либо с замыканиями не сталкивался, либо просто не замечал их что ли.
Просто если бы мне показали кусок кода, который работал бы некорректно из-за неиспользования замыканий (стандартный пример с вызовом функции в цикле), то исправить его я бы сумел. Но написать с нуля и объяснить принцип работы — вряд ли.
Просто если бы мне показали кусок кода, который работал бы некорректно из-за неиспользования замыканий (стандартный пример с вызовом функции в цикле), то исправить его я бы сумел. Но написать с нуля и объяснить принцип работы — вряд ли.
Простите но джаваскрипт разработчик — должен знатьчто такое замыкание. А разработчик претендующий на сеньера долен знать куда больше
1) во первых вы должны нормально общаться с коллегами, описывая вещи своими именами, а не типо «вон та хренька, пришла от сюда и типо вот так»
2) во всей литературе используются эти термины, как вы можете получать нове знания если читая статью 50% терминов вам не знакомы и вы считаете что это ОК?
Есть некая база которую должен знать разработчик (не важно на каком язые он пишет), без этой теоритеческой базы с ним сложно общаться другим и его сложно обучать.
1) во первых вы должны нормально общаться с коллегами, описывая вещи своими именами, а не типо «вон та хренька, пришла от сюда и типо вот так»
2) во всей литературе используются эти термины, как вы можете получать нове знания если читая статью 50% терминов вам не знакомы и вы считаете что это ОК?
Есть некая база которую должен знать разработчик (не важно на каком язые он пишет), без этой теоритеческой базы с ним сложно общаться другим и его сложно обучать.
Понимание основ JS нужно, что бы использовать все его средства к месту, и не создавать дублирующие реализации (если вы не знаете ничего про arguments то когда понадобится выполнить slice, вам потребуется время что бы его сделать. Если допустить, что такие вещи можно и гуглить, то возьмите меня Сишником — я в сях на уровне лаб по сортировке, но перед каждой строчкой могу погуглить и напишу в итоге). Для джуниора простительно не знать отдельные нюансы, но это скорее будет говорить о том, что человек поленился потратить пару-тройку дней (может быть неделю) на изучение своего рабочего инструмента. Именно столько времени я считаю хватит бывалому программисту, что бы проникнутся всеми особенностями самого языка JS и базовых компонентов. Мы же говорит о цели «Frontend Ninja».
Про
Про Кофескрипт: если в компании кофескрипт используется, то пусть про него и спрашивают (одно другое не исключает), но вряд ли есть кофескриптер который не имеет дело на работе с JS кодом.
Значение слов «замыкание», «рекурсия», каких-то базовых шаблонов и типов данных нужно как минимум для общения. Но так же и для упрощения поиска в интернете проблем. И для понимания чужих решений (когда полезете в сырцы библиотек и будете поглядывать комментарии к коду).
Я уверен, что проверять все это можно и нужно. Как лучше это проверить? Это конечно сложный вопрос.
Вот например проверять на боевой задаче то же не всегда разумно: вы скорее всего будете работать с ограниченным набором проектов, и работать придется имея представление о них, а не втягиваться каждый раз. А если на собеседовании дадут задачу на одном из их проектов, который вам не знакомом, вы больше времени потратите на изучение проекта. Полезный навык, не спорю, но и его проверка не всегда отражает суть повседневной работы.
Резюмируя то, что написал: у любой проверки (из текста статьи, или из комментариев) есть свои субъективные составляющие, и потому вопрос лишь в том как трактуются результаты. Но я не согласен с тем «минимумом» который вы считаете надо знать среднему js программисту, и уж тем более «Javascript/Frontend Ninja”.
Про
.split('').reverse().join('') я бы вообще сказал, что это проверка не знаний JS, а умений в голове делать хотя бы не сложные преобразования (в тому случае если ответ надо было дать для конкретной строки).Про Кофескрипт: если в компании кофескрипт используется, то пусть про него и спрашивают (одно другое не исключает), но вряд ли есть кофескриптер который не имеет дело на работе с JS кодом.
Значение слов «замыкание», «рекурсия», каких-то базовых шаблонов и типов данных нужно как минимум для общения. Но так же и для упрощения поиска в интернете проблем. И для понимания чужих решений (когда полезете в сырцы библиотек и будете поглядывать комментарии к коду).
Я уверен, что проверять все это можно и нужно. Как лучше это проверить? Это конечно сложный вопрос.
Вот например проверять на боевой задаче то же не всегда разумно: вы скорее всего будете работать с ограниченным набором проектов, и работать придется имея представление о них, а не втягиваться каждый раз. А если на собеседовании дадут задачу на одном из их проектов, который вам не знакомом, вы больше времени потратите на изучение проекта. Полезный навык, не спорю, но и его проверка не всегда отражает суть повседневной работы.
Резюмируя то, что написал: у любой проверки (из текста статьи, или из комментариев) есть свои субъективные составляющие, и потому вопрос лишь в том как трактуются результаты. Но я не согласен с тем «минимумом» который вы считаете надо знать среднему js программисту, и уж тем более «Javascript/Frontend Ninja”.
Блин, я наверное нарвусь на праведный гнев, но меня обязывает мой ник чего-нибудь написать в этом топике.
Я самоучка. Университет хоть и профильный, но нихрена не дал в плане программирования.
Я не знаю терминов, серьёзно. И когда умные люди начинают говорить про всякие «бинарные деревья» я ввергаюсь в панику и думаю что мой уровень ниже плинтуса, хоть и имею достаточно опыта и знаний в своём деле. Пытаюсь «догнать» терминологию, вот например узнал про замыкания и области видимости функций. Поможет ли мне это в работе? Нет, пытался придумать применение — не нашёл. Упростит ли это поддержку кода? Нет, т.к происходят неочевидные вещи.
Я согласен, бывают разные случаи, в том числе и при оптимизации кода. Так ли сильно нужно это клиентам? Не думаю.
Присоединюсь к мнению — лучше за два дня сделать работающий интерфейс чем за два месяца сделать правильный интерфейс. А быдлокодинг — все через него прошли, и он проходит с опытом. Я искренне буду рад если мне покажут какой то новый способ решения который будет оптимальнее, но пока таких — увы и ах — не находилось(хоть я и не гуру фронтенд разработки, библиотек не писал, и ни разу не TheShock).
Можете хоть сто раз меня назвать Junior и «быдлокодер», но если я встречусь с проблемой которую я не смогу решить — я это загуглю и углублюсь. Пока что в современных практиках я нахожу схожий со своим подход в программировании.
Я самоучка. Университет хоть и профильный, но нихрена не дал в плане программирования.
Я не знаю терминов, серьёзно. И когда умные люди начинают говорить про всякие «бинарные деревья» я ввергаюсь в панику и думаю что мой уровень ниже плинтуса, хоть и имею достаточно опыта и знаний в своём деле. Пытаюсь «догнать» терминологию, вот например узнал про замыкания и области видимости функций. Поможет ли мне это в работе? Нет, пытался придумать применение — не нашёл. Упростит ли это поддержку кода? Нет, т.к происходят неочевидные вещи.
Я согласен, бывают разные случаи, в том числе и при оптимизации кода. Так ли сильно нужно это клиентам? Не думаю.
Присоединюсь к мнению — лучше за два дня сделать работающий интерфейс чем за два месяца сделать правильный интерфейс. А быдлокодинг — все через него прошли, и он проходит с опытом. Я искренне буду рад если мне покажут какой то новый способ решения который будет оптимальнее, но пока таких — увы и ах — не находилось(хоть я и не гуру фронтенд разработки, библиотек не писал, и ни разу не TheShock).
Можете хоть сто раз меня назвать Junior и «быдлокодер», но если я встречусь с проблемой которую я не смогу решить — я это загуглю и углублюсь. Пока что в современных практиках я нахожу схожий со своим подход в программировании.
> вот например узнал про замыкания
Замыкания — очень натуральная штука ведь, я думаю даже, многие их используют даже не задумываясь, что это как-то называется.
Замыкания — очень натуральная штука ведь, я думаю даже, многие их используют даже не задумываясь, что это как-то называется.
Возможно. Просто не силён в терминологии.
Я, например, обычно делаю jQuery-way — если нужно что то пересчитать то вот есть ивент recount и в случае изменения — его нужно дёрнуть, а там подтянутся все необходимые переменные из источников. Таким образом очевидно что конкретно откуда берётся.
Ну и конкретно с замыканиями — в своей практике я не использовал «локальные» функции которые имеют доступ к «приватным» переменным. Возможно я просто не сильно утруждал себя оптимизацией кода и исключением «глобальных переменных»(как пример — ajaxAbort).
На самом деле благодаря таким комментам я всё чаще и чаще задумываюсь о повышении своего уровня, хотя бы для общения на «общепринятом» языке. Но — нет времени на теорию, сейчас больше всего нужно время на изучение новых инструментов разработки. Например я давно хочу сделать «передовой» сайт со всякими фичами вроде SAAS/LESS и full-stack JS сайте. К сожалению, я работаю в достаточно консервативной сфере, где с одной стороны работодатель даёт крайне ограниченное время на такого рода эксперименты, а с другой — менеджеры говорят что клиенты не увидят разницы. Но время на само-обучение я всёравно трачу, иначе просто рано или поздно превращусь в осталого динозавра, как сейчас — прогеры на каком нить делфи.
Я, например, обычно делаю jQuery-way — если нужно что то пересчитать то вот есть ивент recount и в случае изменения — его нужно дёрнуть, а там подтянутся все необходимые переменные из источников. Таким образом очевидно что конкретно откуда берётся.
Ну и конкретно с замыканиями — в своей практике я не использовал «локальные» функции которые имеют доступ к «приватным» переменным. Возможно я просто не сильно утруждал себя оптимизацией кода и исключением «глобальных переменных»(как пример — ajaxAbort).
На самом деле благодаря таким комментам я всё чаще и чаще задумываюсь о повышении своего уровня, хотя бы для общения на «общепринятом» языке. Но — нет времени на теорию, сейчас больше всего нужно время на изучение новых инструментов разработки. Например я давно хочу сделать «передовой» сайт со всякими фичами вроде SAAS/LESS и full-stack JS сайте. К сожалению, я работаю в достаточно консервативной сфере, где с одной стороны работодатель даёт крайне ограниченное время на такого рода эксперименты, а с другой — менеджеры говорят что клиенты не увидят разницы. Но время на само-обучение я всёравно трачу, иначе просто рано или поздно превращусь в осталого динозавра, как сейчас — прогеры на каком нить делфи.
Зачние терминологии, как я написал, нужно в первую очередь для общения и чтения/поиска материалов. Если вы знаете замыкания, используете их, но называете их «та хитрая штука», то это может и не помешать вашей работе, особенное если вы работаете один. Но как только пойдете обсуждать или гуглить, я уверен вы будете спотыкаться о нехватку знаний терминологии. Скорее всего вы так же встретитесь с отдельными терминами в документации того же jQuery (ведь кроме замыкания, есть разная терминология; например «функция-конструктор», «MVC», «синглтон/одиночка», «модуль» — все это из разных областей, но все это термины из мира программирования, которые встретит опытный фронтендер не раз).
Замыкания — их и правда многие знают и используют инстинктивно, еще до изучения такого термина. Если вы их ниразу не использовали, то навреное у вас специфический круг задач, над которыми обсуждаемый здесь JS Ninja работать не захочет — это явно что-то небольшое и не сложное.
А вот когда вы делаете одностраничный сайт, к примеру, и вы вот не знаете термина MVC. Казалось бы, ну и пес с ним. Но незнание термина чаще всего означает не знание подхода стоящим за ним. И начнете вы писать страшный код, с кучей зависимостей колбеками разбросаных по всем модулям, и постепенно изобретете MVC. Или вот не знаете вы что такое Promises… Уже сейчас многие фронтендеры скажут вам, что с ними код становится читаемей. Но да, можно без них писать, заказчик действительно не заметит.
Так что в вопросе незнания терминов, главное разделять знание умного слова и знание того что за ним стоит. Для хорошего развития в гуру фронтенда без знания названий никуда. Вы не сможете читать серьезные материалы, говорить о сложных вещах, потому что когда вы будете говорить в терминах функция-переменная, старшие программисты будут говорить в терминах свойственных языку и его окружению (а порой еще будет влезать всякие умные названия паттернов, к примеру). Коллбек звучит короче чем «та функция которая вызывается внутри функции». И все будут писать с документации: «Вторым параметром передается коллбек».
Вот вы пишете, что узнав про замыкания, не нашли чем это вам поможет. А вы поняли для чего можно их использовать? Я уверен вы их не раз использовали хотя бы в обработчиках событий. А если так, значит вы знали термин «наполовину», т.к. знали что за ним стоит.
Замыкания — их и правда многие знают и используют инстинктивно, еще до изучения такого термина. Если вы их ниразу не использовали, то навреное у вас специфический круг задач, над которыми обсуждаемый здесь JS Ninja работать не захочет — это явно что-то небольшое и не сложное.
А вот когда вы делаете одностраничный сайт, к примеру, и вы вот не знаете термина MVC. Казалось бы, ну и пес с ним. Но незнание термина чаще всего означает не знание подхода стоящим за ним. И начнете вы писать страшный код, с кучей зависимостей колбеками разбросаных по всем модулям, и постепенно изобретете MVC. Или вот не знаете вы что такое Promises… Уже сейчас многие фронтендеры скажут вам, что с ними код становится читаемей. Но да, можно без них писать, заказчик действительно не заметит.
Так что в вопросе незнания терминов, главное разделять знание умного слова и знание того что за ним стоит. Для хорошего развития в гуру фронтенда без знания названий никуда. Вы не сможете читать серьезные материалы, говорить о сложных вещах, потому что когда вы будете говорить в терминах функция-переменная, старшие программисты будут говорить в терминах свойственных языку и его окружению (а порой еще будет влезать всякие умные названия паттернов, к примеру). Коллбек звучит короче чем «та функция которая вызывается внутри функции». И все будут писать с документации: «Вторым параметром передается коллбек».
Вот вы пишете, что узнав про замыкания, не нашли чем это вам поможет. А вы поняли для чего можно их использовать? Я уверен вы их не раз использовали хотя бы в обработчиках событий. А если так, значит вы знали термин «наполовину», т.к. знали что за ним стоит.
Я искренне буду рад если мне покажут какой то новый способ решения который будет оптимальнее, но пока таких — увы и ах — не находилось(хоть я и не гуру фронтенд разработки, библиотек не писал, и ни разу не TheShock).
Ну спасибо, польстили)
Я, кстати, тоже на собеседовании даю пару задачек. Напечатанные на листочке, 5-10 строчек. Такие, чтобы было о чём поговорить. Ответ может быть неправильным, или не совсем корректным, я даже сам могу дать ответ, если вижу, что человек нервничает, абы потом пояснил. Нюансы работы this, замыканий, ссылок. Термины, теория — всё это маловажно, главное понимание.
Иногда рассказываю интересные уникальные решения, пока никто не жаловался)
Действительно хорошее собеседование.
Могу сказать из своего опыта, наверное чуть меньше полусотни собеседований, что такая вторая часть бывает максимум у 10% (в россии, за поседние 5 лет). Остальные либо гоняют тебя по синтаксису, я называю это «собеседование на уровне точек с запятой», либо они изначально и не позиционируют вакансию как «js ninja». А вообще один раз предложили на собеседовании вычислить результат примерно такого выражения:
($=[$=[]][(__=!$+$)[_=-~-~-~$]+({}+$)[_/_]+($$=($_=!''+$)[_/_]+$_[+$])])
з.ы. Видел недавно вакансию javasKript программиста.
Могу сказать из своего опыта, наверное чуть меньше полусотни собеседований, что такая вторая часть бывает максимум у 10% (в россии, за поседние 5 лет). Остальные либо гоняют тебя по синтаксису, я называю это «собеседование на уровне точек с запятой», либо они изначально и не позиционируют вакансию как «js ninja». А вообще один раз предложили на собеседовании вычислить результат примерно такого выражения:
($=[$=[]][(__=!$+$)[_=-~-~-~$]+({}+$)[_/_]+($$=($_=!''+$)[_/_]+$_[+$])])
з.ы. Видел недавно вакансию javasKript программиста.
Приложение должно было иметь чистую MVC структуру, с public/protected методами и всё такое.
Эм, а в JS вообще возможно сделать protected\private свойство\метод, а не private static (который var)? Насколько мне известно — это невозможно на уровне яп вообще никак.
для этого в тестовом задании использовался упомянутый dejavu. это просто OOP-обёртка.
github.com/IndigoUnited/dejavu
github.com/IndigoUnited/dejavu
вообще возможно =) те же замыкания это позволяют делать :-)
но если речь именно о методах, то тут сложнее: либо создавать на каждый объект своё замыкание с приватными методами, либо пихать методы в prototype, но тогда они будут видны снаружи
var lib = (function () {
var privateMethod = function () {
};
var publicMethod = function () {
privateMethod();
};
return {
publicMethod: publicMethod
}
})();
но если речь именно о методах, то тут сложнее: либо создавать на каждый объект своё замыкание с приватными методами, либо пихать методы в prototype, но тогда они будут видны снаружи
В этом варианте возвращается сразу объект, без возможности создать инстанс.
Я имел ввиду при реализации относительно полноценного ООП, что-то вроде этого:
Хотя в теории и для такого можно что-нибудь придумать =) Наверное
Я имел ввиду при реализации относительно полноценного ООП, что-то вроде этого:
var Some = (function(){
function Some(){ *** }; // Конструктор (this ссылается на инстанс Some)
Some.prototype.any = function(){ *** }; // public (this ссылается на инстанс Some)
Some.any = function(){ *** }; // public static (this ссылается на Some)
var blah = function(){ *** }; // private static (this ссылается на Some)
return Some;
})(this);
Some.any(); // вызов public static
(new Some).any(); // вызов конструктор + public
Хотя в теории и для такого можно что-нибудь придумать =) Наверное
Вот варианты. Пожалуй, самое удобное и правильное из этого — символы. Могу еще несколько способов предложить, но они довольно тяжелые.
Есть разные специализации frontend-программистов.
Если нужен «продвинутый» верстальщик, способный к HTML каркасу прикрутить 3-4 плагина jQuery и вывалить с их помощью результат пары ajax запросов — можно не знать разницу между call и apply.
Если надо писать что-то с нуля, разрабатывать API, полностью кастомный UI и т.д. — нужно знать все упомянутое в статье и еще много чего сверху.
Если нужен «продвинутый» верстальщик, способный к HTML каркасу прикрутить 3-4 плагина jQuery и вывалить с их помощью результат пары ajax запросов — можно не знать разницу между call и apply.
Если надо писать что-то с нуля, разрабатывать API, полностью кастомный UI и т.д. — нужно знать все упомянутое в статье и еще много чего сверху.
Понятно, что для написания SQL-запросов не надо знать сильно реляционную алгебру, а для написания макроса для excel, заполняющего автоматически поля, не надо читать Кнута и знать O-символику. Вопрос в том, на какую работу вы устраиваетесь и в том, что от вас может ожидать работодатель при решении потенциальной сложной работы.
В корне не согласен с автором
B зачем такое надо? Мне просто интересно зачем при поиске кандидатов делать основную ставку на стрессоустойчивость? Если в компании данная ситуация постоянного ASAP-а и дедлайна в порядке нормы, то это ни разу не круто. Очевидно, что в компании явно что-то не в порядке с менеджментом, и такого рода собеседование должно быть первым звоночком соискателю — а стоит ли вообще идти в эту компанию? Не, ну правда, нервы-то дороже. Да и решение, которое человек выдает в условиях неоправданно лимитированного времени, вряд ли будет хоть сколько-нибудь поддерживаемым и расширяемым. Непонятно зачем это надо компании, если она занимается более-менее серьезными проектами, а не клепает сайты-однодневки?
Единственное с чем я могу согласиться с автором — это нафиг не нужные логические задачи аля «канализационные люки», «как сдвинуть гору Фудзи» и пр. По-моему даже Google, который ввел моду на них, уже признал бессмысленность такого подхода.
В остальном же мне кажется автору не следует путать кислое с пресным — наследование через прототип и замыкания это как бы основы основ. Как же вы код пишете, не зная этих вещей? Взять вот хотя бы замыкания — если вы будете копаться во внутренностях большинства JS-фреймворков, то там сплошь и рядом замыкания. А ведь если вы позиционируете себя как javascript ninja, то заглядывать под капот так или иначе придется.
И вот как раз-таки не соглашусь, что с ростом числа библиотек все эти знания теряют смысл — зависимость совершенно обратная. Чем больше библиотек, тем лучше человек должен уметь ориентироваться в том, что у них происходит под капотом. Иначе можно всю жизнь быть jQuery-программистом и под любую задачу 2+2 искать плагин.
Мой будущий коллега потом объяснил, что целью этого тестового задания было определить, как я буду работать в условиях жёсткой нехватки времени.
B зачем такое надо? Мне просто интересно зачем при поиске кандидатов делать основную ставку на стрессоустойчивость? Если в компании данная ситуация постоянного ASAP-а и дедлайна в порядке нормы, то это ни разу не круто. Очевидно, что в компании явно что-то не в порядке с менеджментом, и такого рода собеседование должно быть первым звоночком соискателю — а стоит ли вообще идти в эту компанию? Не, ну правда, нервы-то дороже. Да и решение, которое человек выдает в условиях неоправданно лимитированного времени, вряд ли будет хоть сколько-нибудь поддерживаемым и расширяемым. Непонятно зачем это надо компании, если она занимается более-менее серьезными проектами, а не клепает сайты-однодневки?
Все эти вопросы про прототипное наследование, замыкания и круглые канализационные люки можно просто заучить. А вместе с ростом популярности CoffeeScript и разнообразных библиотек и фреймворков они и вовсе теряют всякий смысл.
Единственное с чем я могу согласиться с автором — это нафиг не нужные логические задачи аля «канализационные люки», «как сдвинуть гору Фудзи» и пр. По-моему даже Google, который ввел моду на них, уже признал бессмысленность такого подхода.
В остальном же мне кажется автору не следует путать кислое с пресным — наследование через прототип и замыкания это как бы основы основ. Как же вы код пишете, не зная этих вещей? Взять вот хотя бы замыкания — если вы будете копаться во внутренностях большинства JS-фреймворков, то там сплошь и рядом замыкания. А ведь если вы позиционируете себя как javascript ninja, то заглядывать под капот так или иначе придется.
И вот как раз-таки не соглашусь, что с ростом числа библиотек все эти знания теряют смысл — зависимость совершенно обратная. Чем больше библиотек, тем лучше человек должен уметь ориентироваться в том, что у них происходит под капотом. Иначе можно всю жизнь быть jQuery-программистом и под любую задачу 2+2 искать плагин.
Тут есть одна тонкость. Большинству разработчиков действительно знать все эти тонкости особо не нужно. Но в команде должен быть как минимум один человек, которые примерно представляет себе как работает весь стек технлогий — от транзисторов до jQuery плагинов. Закон протекающих абстракций, понимаешь.
Так вот я прошел стресс-тестовое задание, по типу описанного в посте, в одной крупной и известной, по местным меркам, компании. Управился, все сделал за выделенные 3 часа.
В итоге редложили работу фронт-энд девелопера, предложили хорошие деньги.
Ну, думаю сейчас начнется что-то интересное!
Не тут то было: за почти пол года HTML, CSS/SASS и совсем немножЕчко JS — заскучал. Ничего интересного.
Ухожу через 2 месяца (чтобы было отработанно в сумме пол года и не выглядело будто я не прошел испытательный срок).
Ну и зачем было, спрашивается выставлять все эти супер-требования и давать это стресс-задание, если по факту в компании все расслаблено и без стресса?
В итоге редложили работу фронт-энд девелопера, предложили хорошие деньги.
Ну, думаю сейчас начнется что-то интересное!
Не тут то было: за почти пол года HTML, CSS/SASS и совсем немножЕчко JS — заскучал. Ничего интересного.
Ухожу через 2 месяца (чтобы было отработанно в сумме пол года и не выглядело будто я не прошел испытательный срок).
Ну и зачем было, спрашивается выставлять все эти супер-требования и давать это стресс-задание, если по факту в компании все расслаблено и без стресса?
Подскажите пожалуйста с чего начать, недавно я уволился с должности PHP разработчика и захотелось перейти на JS.
С чего стоит начать обучение, какие фреймворки (если используют) стоит учить?
Есть небольшие знания JS и небольшой опыт работы с jQuery, но всё это в основном на уровне ajax запросов и прочих мелочей как дополнение при разработке фронтенда и бакенда.
С чего стоит начать обучение, какие фреймворки (если используют) стоит учить?
Есть небольшие знания JS и небольшой опыт работы с jQuery, но всё это в основном на уровне ajax запросов и прочих мелочей как дополнение при разработке фронтенда и бакенда.
Я бы посоветовал addyosmani.github.io/backbone-fundamentals/
Но конечно в формате туториала это всё сложно осилить. Я бы посоветовал начать какой-нибудь небольшой личный проект, который бы вам приносило удовольствие разрабатывать.
Чтоб сразу «окунуться» в JS, можно заодно и серверную часть на нём писать, используя Node.js + Express.
Но конечно в формате туториала это всё сложно осилить. Я бы посоветовал начать какой-нибудь небольшой личный проект, который бы вам приносило удовольствие разрабатывать.
Чтоб сразу «окунуться» в JS, можно заодно и серверную часть на нём писать, используя Node.js + Express.
Господа минусующие, вы б хоть писали в чем дело. По-вашему, человеку нужно сейчас «The Good Parts» читать, или сразу «Secrets of Javascript Ninja»?
Есть определённый тип людей, для которых описание всех этих абстарктных проблем и паттернов совершенно не прибавляет понимания языка. Я отношусь именно к этому типу людей и понимание ко мне приходит только во время работы над реальными проектами и реальными задачами.
Поэтому и подобные советы. Если вы придерживаетесь другого мнения, то озвучьте его пожалуйста.
Есть определённый тип людей, для которых описание всех этих абстарктных проблем и паттернов совершенно не прибавляет понимания языка. Я отношусь именно к этому типу людей и понимание ко мне приходит только во время работы над реальными проектами и реальными задачами.
Поэтому и подобные советы. Если вы придерживаетесь другого мнения, то озвучьте его пожалуйста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестовое задание моей мечты