Тестовое задание моей мечты

Похоже некоторые работодатели так и не понимают, что в большинстве случаев с тестовым заданием можно нанять только достаточно среднего разработчика. Потому что человек, знающий себе цену — не будет тратить 6-8 часов дома на выполнение теста, да и 3-4 часа на собеседование (+ дорога) вряд ли найдется в будний день. Конечно, если вы контора уровня Google, Microsoft, Apple, Facebook и т.д. — то вы можете себе такое позволить, но ООО «NoName и Ко» хороших разработчиков с такой стратегией не найдет.

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

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

Сортировка integer? Не слишком экзотично? (:

>>>[11,1,2,3].sort()
[1, 11, 2, 3]

stackoverflow.com/questions/1063007/sort-not-working-with-integers

По дефолту сортируются как строки. Меня как рубиста это удивило в своё время.

Т.е. «требует изучения» — это будет в рабочее время?
>поощряют всевозможные хаки, которые в реальной рабочей обстановке либо вообще не используются, либо гуглятся за минуту.
Именно что спец по JS должен это всё сразу знать. А не говнокодить свои велосипеды или сидеть в гугле из-за того что он не знал решения в пару строк.
Если вы про позицию Junior, то со статьёй можно согласиться, но тогда это надо было озвучить в статье.

Но вы всё равно бы не сдали заказчику результат за 2 часа, судя по тексту — была куча мест, которые «можно было бы сделать лучше», и не работало «переключение страниц».

Плюс, если в команде нормальная ситуация «сделай за 2 часа, пофиг на качество» — наверняка будут и «скоро дедлайн, работаем по 12 часов и без выходных, и конечно без доплаты, или тебе что, пофиг на судьбу проекта».

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

Ну и опять же, новое можно и без чужого пинка опробовать…

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

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

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

> вот например узнал про замыкания

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

Зачние терминологии, как я написал, нужно в первую очередь для общения и чтения/поиска материалов. Если вы знаете замыкания, используете их, но называете их «та хитрая штука», то это может и не помешать вашей работе, особенное если вы работаете один. Но как только пойдете обсуждать или гуглить, я уверен вы будете спотыкаться о нехватку знаний терминологии. Скорее всего вы так же встретитесь с отдельными терминами в документации того же jQuery (ведь кроме замыкания, есть разная терминология; например «функция-конструктор», «MVC», «синглтон/одиночка», «модуль» — все это из разных областей, но все это термины из мира программирования, которые встретит опытный фронтендер не раз).

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

А вот когда вы делаете одностраничный сайт, к примеру, и вы вот не знаете термина MVC. Казалось бы, ну и пес с ним. Но незнание термина чаще всего означает не знание подхода стоящим за ним. И начнете вы писать страшный код, с кучей зависимостей колбеками разбросаных по всем модулям, и постепенно изобретете MVC. Или вот не знаете вы что такое Promises… Уже сейчас многие фронтендеры скажут вам, что с ними код становится читаемей. Но да, можно без них писать, заказчик действительно не заметит.

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

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

Я искренне буду рад если мне покажут какой то новый способ решения который будет оптимальнее, но пока таких — увы и ах — не находилось(хоть я и не гуру фронтенд разработки, библиотек не писал, и ни разу не TheShock).

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

В этом варианте возвращается сразу объект, без возможности создать инстанс.

Я имел ввиду при реализации относительно полноценного ООП, что-то вроде этого:

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

Хотя в теории и для такого можно что-нибудь придумать =) Наверное

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