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

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

Да, эту таблицу видел. Спасибо.
ИМХО, анкета по ссылке немного бестолковая.
Я вот только слышал о MooTools, Prototype, Dojo и ExtJS. А табличную верстку только в письмах видел да паре легаси проектах. Но учить их не собираюсь. Это лишь инструменты, причем некоторые из них устаревшие давно. Подобные анкеты в мире фронтенда будут устаревать быстрей, чем вы их соберете.
Как минимум раз в год надо чистить, согласен

Табличную вёрстку учить несложно, а вот тестировать письма — это тот ещё гемор. Но сейчас есть фреймфорки типа такого mjml.io конечно, он берёт на себя эти знания древних технологий.
А, это про Google Doc? Там технологии 2011 года. Старые, да.

Там в опроснике в паттернах опечатка — composit вместо composite и 3 (три) паттерна под названием mixin.

Исправил
Тема, конечно, любимая холиварная. Но не могли бы вы описать, в чём суть _методологий_ Waterfall и Agile? Кажется мне, что и остальная часть этого опросника — набор случайных слов из разных предметных областей.
Один из важных советом по прохождению интервью: никогда не верить перечисленным в вакансиях спискам требований и технологий. Всегда на месте выяснять что же на самом деле нужно работодателю.

Сравнение: [1] [2] [3] [4]
В свое время видел такую шкалу:
Оцените ваши знания инструмента:
1. Не слышал.
2. Слышал.
3. Видел, как используют.
4. Пробовал.
5. Регулярно использую.
6. Обучаю пользоваться.
7. Читал исходники
8. Реквестил патч-фикс
9. Мейнтейню репозиторий.
10. Я — автор.
Есть ситуации, к применению С++, даже 10 по этой шкале, означает 70% знания. Бьёрна Страуструп.
Интересная шкала, но не очень линейная. середину нужно чуть более дробную.

По своему опыту могу сказать — 7 и 6 (и даже 8 и 5) могут идти и в обратном порядке: например, заслал фикс для какого-нибудь маленького модуля в большом фреймворке, который применил в одном проекте и больше не трогал. Хотя это, конечно, скорее исключение, чем правило.

В шаблонах проектирование mixin встречается 3 раза подряд.
да, удалю лишние копии
592, но я не web программист, думаю простительно.

Список хороший, но получив такое на собеседовании, я предложу уволить архитектора. Потому что в теории это все выглядит красиво, а на практике смесь из нескольких php фреймворков и других языков программирования. Да еще и erlang. И зоопарк из ОС. И еще зачем-то указание Linux, после двух разных дистрибутивов.
Оно вам точно все вместе надо?
Если это web студия, пишушая на заказ, тут другой вопрос конечно, да.
На практике 100% никому не нужно. Достаточно одного из МVCшных фреймворков на бэке и желания изучить другой. То есть проходной порог может быть 25-30%
Не нашёл как прямо там написать комментарий, поэтому напишу сюда.
По ООП:
final — это, может быть ключевое слово из Java, Kotlin, C++ и наверняка из каких-то других языков. Надо, наверное, уточнять язык. А то непонятно.
attribute — может быть из C#, C++, Rust, наверное ещё откуда-то. Может быть общее поняти из ООП.
Короче, есть рац. предложение уточнять откуда понятие.
Посыпаю голову пеплом. Это всё, наверное, из PHP. Я просто с этим языком практически не знаком. Не догадался.
Да, это PHP. Надо уточнять, согласен.
мне в руки попался интересный документ, который не даёт успокоиться до сих пор. Он мешает мне поставить самому себе 100% владения айтишными хард и софт скилам.

Вот это на мой взгляд очень важно для любого разработчика. Не придти в состояние уверенности «всезнания» или почти «всезнания». Встретить что-то (книгу, анкету, статью, доклад, не суть важно), что покажет тебе, что на самом-то деле ты ничего не знаешь. Что в казалось бы изученной тобой вдоль и поперек области еще столько всего, что даже непонятно, с какой стороны начать все это изучать. И не забывать про это в дальнейшем. У меня лично это была книга Andrei Alexandrescu «Modern C++ Design: Generic Programming and Design Patterns Applied» после первых же глав которой я с очумелым видом, понял, что вообще ничего не знаю о C++
Когда оценка знаний по технологиям и программированию сводится к знаниям фреймворков — это тупиковая ветвь развития.
Жизненный цикл у них с каждым новым всё меньше и меньше, не говоря уже о разнообразии, которые выражается не только в синтаксисе, но и в походе к решению задач в целом.
Простой пример:
Сегодня ты знаешь Angular — завтра его не стало. Тебя на свалку.
Сегодня ты знаешь JS — завтра не стало Angular. Ты до сих пор знаешь JS.
Хотя если не стало JS, то копаем глубже к знаниям основ программирования, алгоритмов.
Мысль: Жизненный цикл ЯП выше чем фреймворков.
Если ты не знаешь/не сталкивался/не работал с Ember, Backbone или ещё каким фреймворком, то это не значит что ты не знаешь JavaScript.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.