Открыть список
Как стать автором
Обновить

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

«Если человек ходит по собеседованиям пачками и/или в недавнем прошлом прочитал про аргументы bind и про специфику поведения box-sizing — то он существенно более крутой специалист, чем тот который не ходит и не прочитал».

Я правильно понял один из главных тезисов статьи?
Нет, неправильно. Приведенная форма это просто конспект интервью, нет такого критерия, что должны быть отвечены все вопросы. Тем не менее, человек который не владеет bind/call/apply, не знает каррирование и не понимает как работает event loop имеет хорошие шансы получить отказ.
Ну окей, смотрите, я работаю пять лет в одной компании, разработал архитектуру фронтенда, на которой запускаются все новые проекты, программами пользуются сотни тысяч людей, у меня в команде несколько человек, и мы закрываем задачи хорошо и в срок и заключаем новые контракты. Ну короче, всё огонь.

И я не имею ни какого представления, что такое Event loop, а про bind/call/apply и каррирование прочитал в какой-то статье однажды и забыл, потому, что никогда не использовал на работе. (Ну ладно, bind использовал).

По вашей методике я даже на джуна не потяну. Как же так?
очевидно вы не подходите для позиции junior/middle/senior front-end developer. Ищите вакансию на которой не нужно работать с кодом непосредственно.
Под словом разработал я подразумевал, что я не только придумал, но и сам и написал всю эту основу. Вот прямо на JS.

Суть в том, что я, например, использую то же каррирование и event loop, только я не знал, что они так называются.
Вопросы же не обязательно впрямую задаются, можно попросить разобрать что делает код, или попросить исправить его, чтобы он делал то, что нужно.
Тем не менее, человек который не владеет bind/call/apply, не знает каррирование и не понимает как работает event loop имеет хорошие шансы получить отказ.

Ну то есть я таки понял всё правильно. Спасибо.

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

Что из этого мы видим в статье? Да нифига не видим, автор уже куда-то потерялся на ранжировании. Если кандидат знает аргументы bind и event loop, но не может написать кода — это лучше или хуже кандидата, который теорию не знает, но код пишет? Судя по тому, что автор статьи в своей анкете запихал написание кода в самый конец — я прям готов предположить, что для него главное, чтоб аргументы bind посреди ночи рассказывали на память.

PS: Из всех нормальных процессов найма, виденных лично мной (с обоих сторон), самые адекватные из них следовали простому и нехитрому пути:
1) убедиться в том, что кандидат общечеловечески адекватен и плюс-минус подходит коллективу;
2) убедиться в том, что он может сам писать код в необходимой области;
3) на оставшееся время — поговорить за жизнь и поотвечать на вопросы, уменьшая шансы того, что в недалёком будущем чего-то резко не сложится.
4) если всё ок — нанять на испытательный срок и смотреть на результаты работы.
Если кандидат не знает теорию, но код пишет, то вовсе не очевидно, что код он пишет правильно, наилучшим образом, и при этом понимает что именно он пишет. Нормальное знание синтаксиса и внутренней логики фреймворка позволяет отлаживать сложные баги, и иногда залезать в исходники самого фреймворка чтобы разобраться что происходит.
Если кандидат не знает теорию, но код пишет, то вовсе не очевидно, что код он пишет правильно, наилучшим образом, и при этом понимает что именно он пишет.

Ну да. Зато если уж аргументы у bind все знает — то наверное пишет всё правильно, наилучшим образом, и при этом всё-всё понимает ^_^

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

Нормальное знание синтаксиса и внутренней логики фреймворка позволяет отлаживать сложные баги

А незнание граничных наворотов синтаксиса и внутренней логики фреймворка — позволяет писать простой тупой код с высоким bus factor, который легко читается и отлично поддерживается ^_^

Но на самом деле соль даже не в этом. От того, что кандидат не знает, что bind можно применять для каррирования — его код в подавляющем большинстве случаев (>98%) будет не хуже. От того, что он знает каррирование и лепит его куда не попадя — хуже будет в десятки раз сильнее. Нет ничего печальнее умников, делающих красно-чёрные деревья, хэшмапы, собственные сортировки, каррирование, и прочую муть там, где достаточно банальных простых переборов, массивов, .sort(), и последовательного вызова пары методов.
Полностью согласен с вами, все мои испытательные сроки заканчивались повышением в должности и расширением фронта работ, при этом всю теорию я безбожно сливал. Схема приема на работы описанная вами единственный шанс для сильных самоучек, без профильного образования, получить работу и принести пользу компании.
Работаю 5 лет на фронте. Сменил три работы и прошел очень большое количество интервью. Постоянная проблема, это техническая часть интервью, там где она есть я ее постоянно заваливаю, там где не спрашивают получаю приглашение и хорошо работаю. Я не могу написать пузырьковую сортировку в течении 5 мин или рассказать каким способом я реализую паттерны проектирования в верстке приложений (вообще не представляю как отвечать на данный вопрос). Event loop для меня темный лес. ПОЧЕМУ на собеседованиях никто не спрашивает по тем задачам которые тебе действительно необходимо будет решать на своем рабочем месте? Вы вообще часто пишете свою реализацию сортировки в продакшен?
Вот обычно я так же и отвечаю на собеседовании. Зачем изобретать велосипед, если он есть? Я за всё время программирования ни разу её не использовала. И если я её сходу не сформулирую, это значит я не спец? Ну прочитала пару раз и я про неё и забыла, т.к. в работе она мне просто не нужна (я про само знание алгоритма веду речь).
Фронтэнд такая же инженерная специальность, как и другие. Почему-то C++ или java инженеры не стесняются знать модель памяти x86 процессора и сложность основных алгоритмов, а фронты за 5 лет ни разу не открывают MDN чтобы понять в каком порядке приходят асинхронные коллбэки.
Я не уверен что все специалисты С++ или java знают модели памяти х86 и сложность основных алгоритмов. Если знают — отлично, если не знают и в работе не используют то ничего страшного в этом не вижу. Я работаю на фронтенде хорошо знаю UX/UI, отлично верстку имею компетенции в маркетинге и выводе продукта на рынок. Я прекрасно осознаю слабость своих знаний в области JS, но я и не претендую на должность синьора. При этом моя ценность для компании может быть очень высока. Обычно интервью никак не учитывает софт скилы и как следствие компании теряют хороших специалистов на стыке специализаций.

Я поэтому спрашиваю не "расскажите мне, что такое <умный термин>", а "как в <ваш основной фреймворк> работает <очень важный компонент> внутри".


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


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

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


Просто потом всегда либо находились либо какие-то другие проблемы(с той или другой стороны) или просто по какой-то причине я выбирал другие фирмы.


И не то чтобы это было прямо показательно или на основании этого стоит выводить глобальные правила для всех. Но для меня это интересный факт :)

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

Информация

Дата основания
1993
Местоположение
США
Сайт
www.epam.com
Численность
свыше 10 000 человек
Дата регистрации
Представитель
vesyolkinaolga

Блог на Хабре