Комментарии 26
По-моему, уровень фронтендера можно проверить по реакции на ответы на эти вопросы.
Тут конечно много к чему можно придраться, но
> 8. Чем отличаются PUT- и POST-запросы?
Ну вы хоть думайте, прежде чем такое писать. Это просто разные методы запроса. Все. Конец.
Никаких «этот только обновляет данные», «этот идемпотентный».
Можно сделать удаление данных на PUT и добавление на DELETE. Это лишь реализация.
Да, почему-то тоже резануло. Это всего лишь рекомендация, договорённость. А сделать можно все, что угодно. Создание на Delete — да почему бы и нет
Лично я на собеседованиях именно Ваш ответ засчитаю как верный, а если кандидат не понимает, то всегда объясню, что это всего лишь вопросы семантики. Так что, вопрос хороший :)
Ответ нормальный, это правда, но не вся.

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

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

Как гласит поговорка: правильно поставленный вопрос — это уже половина ответа.


О разности POST и PUT в RFC:
tools.ietf.org/html/rfc7231#section-4.3.4
The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as
replacing the state of the target resource. Hence, the intent of PUT
is idempotent and visible to intermediaries, even though the exact
effect is only known by the origin server.


Также POST используется для вызова Controller (REST, 4-й Resource Archetype).
Ну такое себе. С таким же успехом можно спросить в чем разница между input и textarea, ожидая что кандидат расскажет разницу в синтаксисе биндинга значения в derbyjs. Ну а чё, «я так вижу».
Можно сделать удаление данных на PUT. Можно сделать #define TRUE FALSE. А можно почитать RFC 2616 где сказано, что GET, HEAD, PUT and DELETE по стандарту должны быть идемпотентны. Не спорю, на бэкенде можно что угодно понаписать, только зачем это фронтендеру?
RFC7231 что-то объявил про идемпотентность? Мелочь какая, это всего лишь стандарт на HTTP-протокол, который используешь, ему можно не следовать. Удиви лучше всех, кто потом в твой проект заглянет и будет разбираться, почему всё взорвалось.
Да вашу ж налево. Где-то было в вопросе про протокол?
Вопрос был «чем отличаются» — отличаются строчкой method. Все.

Вы своими ответами с углублениями в протоколы докатитесь до физического уровня. А че, там напряжение будет разное в PUT и POST в разные моменты времени.
Ну и где по вашему определяется, что есть POST запрос, а что есть PUT запрос? На что общее должны опираться фронт и бек, когда используют эти термины?
Ура, хоть кто-то это написал. Ведь разница между «этот запрос идемпотентный» и «его реализация на сервере по стандарту должна быть идемпотентной» достаточно большая.
Можно еще коды ошибок креативно использовать, код 200 возвращать при ошибке сервера, а 500 при успехе. А что, ведь это тоже всего лишь часть стандарта на HTTP-протокол.

Так же как с id и классами, может быть несколько элементов с одинаковыми id и их без проблем можно получить через селекторные запросы. И класс может быть представлен всего одним элементом. Это всего лишь соглашение.

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

Вы реально такие вопросы задаете?! Ну просто они только для совсем джунов годятся

Когда-то ещё студентом читал книжку по html/css и там был момент, когда автор рассказывает в чем отличие тега < b > от < strong > и говорит, что такое обязательно! спросят на собеседовании.
На первых собеседованиях, конечно же, ждал такого вопроса :)))

Скорее это вопросы для позиции мидла среди джунов. Если это первая вакансия фронта для опрашиваемого человека, то вполне можно эти вопросы задать. Но для фронта с опытом (даже с однолетним) минимум половина этих вопросов — это трата времени. Учитывая, сколько приходится порой прособеседовать кандидатов, вопросик про разницу между span и div влетит в серьезную копеечку.

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

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

Так и не понял автору нужно подтянуть английский или русский? Фраза «Имена классов (class) не являются уникальными.» мне понятно, но коряво и non sense/;. «псевдоклассы используются для описания стилей элементов» в оригинале «used to define the special state of an element», что корректней было бы перевести: задают особые/специальные состояния для элементов DOM. Дальше читал оригинал

Мне кажется что эти вопросы не показывают знаний как фронтендера, как верстальщика возможно. Всю статью можно было сократить в 2 линки в итоге.

Если я ответил на 14 вопросов? Меня возьмут? И куда отправлять резюме?

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

Ложным в JavaScript является значение false и все. То о чем идёт речь в посте — скорее звучит как "квази ложные" или falsely.

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

Информация

Дата основания
Местоположение
Россия
Сайт
ruvds.com
Численность
11–30 человек
Дата регистрации

Блог на Хабре