Русский
Русский
English
Статистика
Реклама

Цепи маркова

Где я и где конечный автомат? Доклад Вадима Пацева оматематике во фронтенде

10.04.2021 12:12:31 | Автор: admin
Некоторые фронтенд-разработчики полушутливо называют себя форма-клепатель. Это не так. Руководитель фронтенда Яндекс.Маршрутизации Вадим Пацев поставил себе задачу на примере развития и уточнения одной простой задачи взаимодействия с пользователем показать: не стоит бояться лезть в такие вещи, как конечный автомат, цепи Маркова и так далее. Во фронтенде тоже есть место взрослым архитектурным паттернам и алгоритмам. Ссылка на видео в конце текста.



Меня зовут Вадим Пацев, я долгое время работаю в Яндексе, участвовал в таких проектах, как Я.ру, Музыка, Почта, Диск, а также в проектах вне Яндекса, это Roborace, система управления гонками беспилотных автомобилей, и ExperimentX комплекс по анализу крови. Вообще, я люблю программировать, занимаюсь этим достаточно давно, и это одна из причин, почему я тут и хочу вам рассказать про всякие интересные вещи.

Intro


Сразу дисклеймер: я буду рассказывать о проекте не про Яндекс. Как вы заметили, оформление не яндексовое, и тут не будет ничего связанного с Яндексом. И еще один дисклеймер: все детали проекта вымышленные, любые совпадения с реальными проектами случайные, потому что так сложилось.

Я довольно много собеседую, и часто фронтенд-разработчики говорят мне в полушутку: мы форма-клепатели, делаем кнопочки, формы, простые вещи. И когда мы читаем или слышим про всякие конечные автоматы, математику, вероятности и так далее, встает вопрос: где я, а где все это? У нас простая сфера, мы делаем несложные вещи, и вообще, все это больше про дизайн, нежели про программирование.

Сегодня я хочу рассказать как раз не про формы и кнопки. Забавный момент: параллельно со мной идет секция Виталия Фридмана как раз про то, как правильно делать формы и кнопки в интернете. Я сегодня буду говорить не про это, а расскажу об одной нашей задаче, о том, как она развивалась и к чему мы пришли.

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

Я затрону концепцию конечного автомата надеюсь, что вы с ней знакомы, и еще одну математическую концепцию: цепи Маркова. Это некое продолжение конечного автомата, они довольно тесно связаны.

Контекст


Что это за задача, в каком контексте все происходило?

Мы работали с людьми искусства. Допустим, это были люди, которые делают кино. И они хотели сделать публичное мероприятие на сотни человек. Несколько площадок, здания, открытое пространство. В зданиях целые этажи, переходы между зданиями и так далее. Это несколько стоящих зданий, там можно получить интересный опыт.



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

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

Раз мы тут на фронтенд-конференции, то допустим, что решение было написано на React Native, но это не так важно.

Важное уточнение: сразу стало понятно, что площадки довольно сложные с точки зрения логистики. Много этажей, открытые пространства и так далее. И мы не могли делать хорошее покрытие Wi-Fi. То есть наши устройства не всегда были в сети, вынуждены были работать автономно. Мы не могли централизованно с сервера управлять тем, как работают эти навигаторы.

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

Линейные сценарии


Итак, нам надо сделать навигацию, пошаговую инструкцию.


Окей, давайте сделаем простой сценарный движок: возьмем Redux и сделаем такую декларативную структуру, массив, в котором декларативно опишем каждый шаг.

В терминах Redux это будет некий action, который запускается и что-то показывает на экране. Опционально у него может быть другой action, то есть тот, который надо делать дальше. А также может быть фидбэк. То есть если мы показываем пользователю, где кнопки, то он выбирает одну из них и дальше либо идет по сценарию, по которому шел до этого, либо перекидывается на другой сценарий. Это обычный декларативный сценарий, который можно написать в терминах Redux.


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

Важно: то, что мы сделали на Redux, уже является конечным автоматом. Это математическая абстракция, модель дискретного устройства, имеющего один вход, один выход и в каждый момент времени находящегося в одном состоянии из множества возможных.

Наверное, для вас не секрет, что философия работы Redux связана с конечным автоматом. В машине состояний системы store определяет состояние, action вызывает работу reducers. Reducers изменяют состояние системы, система переводит в новое состояние store, то есть возникает новое состояние автомата.


Такое решение работает, и оно довольно простое. Мы берем обычный state management, предустановленный набор сценариев. Запускаем машинку. Она сама переключает шаги.

Так как есть изначально сформулированный сценарий, то сразу есть и некие рельсы, по которым идут пользователи. Это может работать офлайн, онлайн, неважно.

Мы можем изменять сценарий на лету, каждый шаг. Если у нас есть сеть, мы можем перезапрашивать у сервера, получать новый набор сценариев. Дальше пользователь пойдет по другим рельсам. Могут быть всякие казусы: например, при обновлении сценария один на второй изменился порядок шагов, и пользователь на каком-то шаге два раза сходил туда-обратно. Такое бывает.


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

Они походили, машинка поработала, поводила людей более-менее рандомно в смысле распределения сценариев по людям. Люди распределились по площадке, начали заходить в комнаты все работало достаточно неплохо.

Стало понятно, что при таких масштабах, когда есть всего сто участников и пять-десять сценариев, нет необходимости в распределении ресурсов. Площадки довольно большие, комнат и актеров довольно много, на таких масштабах все работает весьма неплохо. На этом этапе задачу выполнили.

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


Также пять-десять сценариев это тоже не совсем желаемое разнообразие. Хочется намного больше разных сценариев, намного больше вариативности того, что может происходить на площадке.

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

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

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

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


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

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

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

Кроме того, сразу стало понятно, что физические ресурсы это бутылочное горлышко. На таком масштабе темных комнат не хватает, актеров не хватает, ничего не хватает.

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

Что мы поняли? Нужна автоматическая логистика потоков. Нам нужно сделать такую систему, которая нивелирует человеческий фактор, автоматом может распределять людей по нужным трекам и включать нужные сценарии, чтобы это работало само.


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

Дальше нужно сделать набор сценариев, запустить их. Машинки должны виртуально работать, перещелкивать сценарии и так далее. Люди куда-то идут, куда-то доходят. Мы сразу видим, насколько работают придуманные сценарии.

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

Лирическое отступление. Разработка чат-бота весьма похожа на то, что я описал. К вам приходят с задачей, говорят, что есть сценарии для взаимодействия с пользователями и их надо как-то спрограммировать. Приходит пользователь, ему задаются вопросы, шаги, он отвечает и получает какой-то результат. Могут быть разные сценарии и так далее, все абсолютно то же самое.

Но если вы разрабатывали чат-ботов или пользовались ими, то вам сразу видны эти рельсы, сразу видно: если происходит шаг вправо, шаг влево от сценария, то бот перестает тебя понимать. Теряется магия того, что ты общаешься с умным существом.

У нас примерно та же история: есть рельсы и любой шаг вправо-влево ошибка. Это сразу ломает весь user experience. Требовалось другое решение.

У нас был опыт работы с чат-ботами, мы работали с Dialogflow. Это стартап, который впоследствии купил Google. Они сделали систему, которая позволяет строить нелинейные сценарии, как раз то, что нам было нужно.

Есть некоторая предметная область, с помощью которой можно строить сценарии так, что они становятся не очень похожи на рельсы. Нам было нужно именно это, мы применили их предметную область у себя. На самом деле это был качественный переход, потому что нам надо было уйти от простой state-машины к более сложному решению.

Конечный автомат


Из чего состоит более сложный конечный автомат?


У нас были декларативные сценарии и сигналы. Мы делаем три новых сущности, в которые конвертируем уже существующие сценарии. Это можно сделать автоматически. Новые сущности это Activity (активность), Trigger и Interaction (взаимодействие).



Activity регистрирует то, что увидел пользователь, и его действия в ответ на это. Если ему просто что-то показали на экране, это просто регистрация того, что показали. Если ему показали кнопки, то мы записываем то, на какую кнопку он нажал.

Технически это тоже выглядит как декларативная структура. Interaction взаимодействие, после которого это Activity произошло. Trigger то, что вызвало это взаимодействие. Некий фидбек это то, на что нажал пользователь, и так далее. Metadata контекст, в котором это было сделано: сколько времени пользователь потратил на данную активность, какой был заряд батареи, какие биконы были вокруг.


Trigger запускает взаимодействие. Это тоже декларативная структура, она состоит из Interaction, того взаимодействия, которое мы запускаем; и из условия, при которых этот Trigger срабатывает. В нашем случае там мог быть либо определенный набор Activity, определенный контекст, который уже есть у пользователя, либо сигнал то, что приходит извне.

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


Последнее Interaction, более знакомая нам структура. Это стандартный Redux action, который меняет локальное состояние приложения, показывает на экране какие-то вещи, выполняет взаимодействие, то есть переводит локальную state-машину, которую мы делали до этого, в некое новое состояние.

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


Еще раз: Activity однозначно определяет состояние нового конечного автомата. У пользователя сначала нет никаких Activities, пустое состояние. Потом они начинают накапливаться.

Каждый раз, когда появляется новая Activity, появляется и новое состояние системы. Набор однозначен, так что система находится в однозначном состоянии.

У Trigger есть некоторые условия, которые завязаны на Activity, на эти состояния. И мы, имея одно состояние, выбираем набор Triggers, которые могут сейчас привести систему в новое состояние.

И есть Interaction, который переводит систему в новое состояние.

Схематично это выглядит так.

У нас имеется унекоторое множество состояний, в которых может быть система. Это возможный набор Activities, которые пользователь может собрать за свой путь.



Существуют Triggers, которые определяют, как система переходит из одного состояния в другое. Они описаны в conditions. Там могут быть описаны сигналы, которые просто из любой точки приводят систему в любую другую точку. Это нужно для ручного управления. А Interactions осуществляют регистрацию нового Activity и переход в новое состояние.



Набор сущностей Trigger и Interaction, то есть два набора возможных переходов и нулевое пустое состояние определяют работу системы. Мы закидываем набор Trigger/Interaction, при нулевом состоянии срабатывает первый Trigger.

Регистрируется первая Activity. Срабатывает еще один Trigger, который запускает какой-то Interaction, регистрируется новая Activity. Система переходит в новое состояние, и так далее. Это такая автономная система, которая примерно так же, как до этого по сценариям, но уже чуть более сложным, начинает работать сама.

То, как мы регистрируем Activity, большой источник аналитических данных. Мы не только регистрируем некий path, путь по всем возможным состояниям, но и регистрируем там метаданные: сколько времени понадобилось, какое было окружение и так далее. Из этого уже можно сделать некие выводы.

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

Цепи Маркова


Дальше речь пойдет про цепи Маркова. К конечному автомату мы добавляем вероятности.

Еще одно лирическое отступление. Что такое вообще марковские процессы, цепи Маркова? Последовательность случайных событий с конечным или счетным числом исходов, где вероятность наступления каждого события зависит от состояния, достигнутого в предыдущем событии.

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


Схематично выглядит так. У нас есть некоторое количество возможных состояний. Для каждого состояния есть вычисленная вероятность перехода из состояния например, из S1 в S3.

Вероятность, что дальше произойдет переход S3-S4 или S3-S5, никак не зависит от того, как мы попали в S3. Мы могли как-то по-другому попасть в это состояние, но с точки зрения этой картины ничего бы не изменилось. Это и есть, вкратце, марковское свойство системы.


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

Дальше срабатывают какие-то Triggers, их может быть несколько. Тогда мы рандомно выбираем. Если Trigger один, тогда вероятность перехода в следующее состояние равняется единице.

Марковский процесс, которым мы усложнили наш конечный автомат, позволяет посчитать вероятность срабатывания Trigger через n шагов. Здесь написаны формулы, я могу их озвучить. Вероятность перехода из состояния j в состояние i за m шагов равна сумме вероятности перехода из i в k, умноженной на вероятность перехода из j в k при m минус первом шаге. Это простая формула, описывающая довольно сложные вычисления.

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

Итак, еще раз. Есть конечный автомат множество состояний, в котором может находиться система. Есть Triggers, возможности перехода из одного состояния в другое.



Есть сигналы, которые переводят систему сразу в нужное состояние. И также есть вероятности перехода из одного состояния в другое, чтобы мы могли воспользоваться математическим аппаратом цепей Маркова.


Все это дает нам следующее. Мы можем с какой-то долей вероятности посчитать, в каком состоянии будет система через N шагов. Это дает нам довольно интересный инсайт. Например, через сколько шагов и какому количеству людей нужно будет воспользоваться каким-то ресурсом.

Либо мы можем понять, через какое время у нас с площадки уйдет сто человек и удастся запустить еще сто человек.

Также этот математический аппарат позволяет нам тестировать наборы Trigger/Interaction. Допустим, мы сделали набор Triggers, запускаем эту машинку. Проверяем ее на тысяче разных пользователей, которые рандомно нажимают на кнопки, рандомно делают выбор. Мы вычисляем вероятности, с которыми пользователи были в определенных участках, то есть в определенных состояниях нашей системы. И дальше понимаем, как вообще распределяются потоки, нагрузка и так далее.

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


В итоге мы получили модель поведения пользователей. Она может быть реализована на клиенте и на сервере, она синхронизируется с помощью Activity, Trigger и Interaction. То есть мы, с одной стороны, с клиента, посылаем Activity в сторону сервера и тем самым уточняем модель, меняем состояние на сервере. И наоборот, можно одновременно изменять наборы Trigger и Interaction на борту телефонов и на сервере.

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

Потом, когда мы поняли, что данное сочетание Trigger и Interaction работает лучше, мы посылаем его на клиента и жизнь на площадке начинает жить по этим новым правилам. Это можно делать несколько раз, если есть сеть.

Если сети нет, то система работает так же, как и работала, по старым правилам. Когда придут Activities, мы обновим модели на сервере, начнем заново обучать нашу систему и так далее.

Всегда есть некие вероятностные оценки потребности в том или ином ресурсе через какое-то время. Если мы замеряем, за сколько происходят шаги в тех или иных Triggers, то можем посчитать модели пользователей, которые есть сейчас на клиенте и сервере, и когда понадобятся такие-то ресурсы. И индикативно показать на дашборде людям, что сейчас нужно открыть новые комнаты либо вообще закрыть часть сценариев, потому что нет актеров. То есть в реальном времени реагировать на происходящее.

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

Еще один забавный момент, к которому мы и стремились: мы предлагаем рандомные Interaction. То есть когда в системе всплывает несколько Triggers с одинаковым весом и одинаковой вероятностью перехода, система сама выбирает какой-то рандомный Trigger и у пользователя на экране появляются рандомные предложения либо рандомные истории.

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

Outro


Цепи Маркова, конечный автомат всё, о чем я сейчас рассказал, это всё в контексте фронтенда. У нас был React Native плюс Redux. Технически все это было сделано на фронтовых технологиях и находилось в поле ответственности фронтенд-разработчика.


Но нельзя сказать, что есть какой-то ряд задач, которые надо решать так. Основная мысль в другом. Мы делаем решение, потом сталкиваемся с новой проблемой. И тут мы можем сказать: окей, есть привычные для нас фронтовые решения, Redux и так далее. Но также мы можем оглянуться вокруг, посмотреть, какие, например, есть другие абстракции, заглянуть в теорию массового обслуживания, в построение чат-ботов. И вообще в те абстракции, которые уже есть в теории Computer Science и математики, статистики. И найти там какое-то вдохновение для более интересного и гибкого решения.

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

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

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

Здесь я собрал несколько ссылок на материалы:

  • Хорошая статья на Smashing Magazine про state-машины, там хорошо описано, как они работают поверх Redux.
  • Цепи Маркова, краткое объяснение довольно простым языком на Brilliant.
  • И очень хорошая видеолекция от профессора из MIT, в которой очень хорошо рассказывается математический аппарат цепей Маркова.

Спасибо за внимание.



Смотреть видео доклада
Подробнее..

Сертификация. Стоит ли пользоваться дампами и при чем здесь цепи Маркова?

02.09.2020 18:14:51 | Автор: admin
Более 20 лет назад я заинтересовался телекомом. Я начал с чтения книжек, одной из которых был курс CCNA. Тогда это была довольно тоненькая книжечка с FDDI, Token Ring, ISDN и подобными вещами, о которых новое поколение сетевиков только слышали. И тогда я впервые прочитал про CCIE сертификацию. У меня осталось впечатление, что обладатели этого статуса являются воистину IT богами. Конечно же, мне захотелось достичь этого сетевого самадхи.

С тех пор прошло много времени. Я получил CCNA потом CCNP, с успехом просрочил все эти сертификаты за ненужностью и лет через 10 стал CCIE. Я по-прежнему занимаюсь сетями, и, надо сказать, похоже, люблю свою работу, но романтизм, конечно, прошел. Двадцать лет назад отношение ко всему этому было совсем другим. Это был драйв, это было настоящее приключение.

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

Честный подход


Давайте попробуем понять, какой подход оценки нашего знания был бы максимально честным?

  • В качестве первого условия я бы назвал ясное определение круга теоретических вопросов и практических навыков, проверяемых тестированием.
  • Далее, хотелось бы, чтобы была разумная детализированность и специфичность. Какой смысл узнавать насколько хорошо я знаю несущественные в моей работе детали, и могу ли я безошибочно сделать/вспомнить/объяснить то, что пригодится мне пару раз в жизни и что легко гуглится за одну минуту. Хочется, чтобы вопросы были по существу.
  • И третий, достаточно важный для данной статьи компонент это то, что я бы хотел, чтобы проверялись именно мои навыки и знание, необходимое мне в моей профессиональной деятельности, а не навыки сдавать данный тип экзамена.

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

Для определенности будем говорить именно о тестировании с бинарным результатом: сдал (получи сертификат) / не сдал (нет сертификата). Тогда результаты экзамена в одном из самых простых вариантов мы можем представить в виде следующей диаграммы:



Стрелки $p_{11}$, $p_{12}$, $p_{13}$ обозначают вероятности перехода из одного состояния в другое. Так, $p_{11}$ обозначает вероятность того, что вы после безуспешной попытки пытаетесь сдать экзамен еще раз. Если нет перехода между состояниями, то это значит, что вероятность перехода равна 0.

Например, вероятности могут быть распределены следующим образом



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

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

Пример 1

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

Пример 2

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

Но если мы говорим про популярные сертификаты, то этот подход не работает. Причин для этого несколько, например, приведу две:

  • такой индивидуальной подход слишком дорог
  • нужна стандартизация

Справедливый подход


Обычно мы сталкиваемся с ситуацией, когда мы должны готовиться именно к экзамену. Я говорю не про теоретический материал и не о навыках, которыми мы должны обладать и которые безусловно важны и полезны в нашей повседневной трудовой деятельности. Я говорю о том, что мы должны вырабатывать навыки специально под данный тип экзамена (я все еще предполагаю, что дампов нет), и если вы не будете тренировать этот специфический навык, то вероятность успеха значительно снижается.

Пример

Мне кажется, что хорошим примером такого подхода является CISSP сертификация. Если вы хотите сдать этот экзамен, то обычная рекомендуется заключается в том, что вы должны сначала выучить всю теорию, а потом потратить столько же времени, отвечая на вопросы (не дампы), специально составленные для вашей тренировки. При такой подготовке в общей сложности приходится отвечать на несколько тысяч вопросов (во всяком случае, так было у меня). Таким образом, вы тренируете навык быстро понимать суть вопроса, понимать логику и смыслы, вкладываемые вендором, и просто учитесь сохранять внимательность в течении нескольких часов в условиях стресса. Таким же типом экзамена являются тесты, проводимые при приеме на работу (числовые, вербальные, логические, ...).

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

Этот подход по-прежнему можно считать довольно честным, потому что здесь все находятся в приблизительно в равных условиях, поэтому я назвал этот тип экзамена справедливым подходом.

Каким будет граф переходов в данном случае?



Мы имеем следующие состояния:

  1. Нет опыта. Вы решили сдавать экзамен абсолютно честно, то есть, не тренируя специально технику сдачи экзамена. Вы знаете теорию и обладаете необходимыми практическими навыками. Вам кажется, что этого должно быть достаточно, чтобы получить достойную оценку.
  2. Не сдал. Опыт. Это состояние, когда вы имеете дополнительное знание и навыки, касающееся процедуры проведения экзамена. Это знание было получено или в результате безуспешной попытки, или в результате целенаправленной подготовки. Еще раз напомню, что в данном случае речь не идет о дампах.
  3. Сдал.
  4. Сдался.

Стрелки $p_{12}$, $p_{13}$, $p_{14}$, обозначают вероятности перехода из одного состояния в другое. Если нет перехода между состояниями, то это значит, что вероятность перехода равна 0.

А теперь зададимся вопросом: насколько уменьшится вероятность вашей сдачи, если вы будете ожидать честного подхода, и просто понадеетесь на ваш опыт и знания и не будете специально готовиться к технике сдачи данного экзамена (то есть нас интересует $p_{13}$)? Конечно, если сложность экзамена такая же, как и в случае честного подхода, то ваши шансы будут такими же. Но мне кажется разумно сделать одно важное допущение, которое кардинально меняет ситуацию.

Давайте предположим, что вендор старается сохранять определенную сложность теста, и делает это, удерживая процент сдачи не выше определенного уровня. Предположим, что уровень сложности вопросов подбирается таким образом, чтобы проходной процент был бы не выше 50%.

Зададим для определенности следующие условия:

  • Вендор поддерживает сложность задания на таком уровне, чтобы в среднем не более 50% претендентов успешно выполняли бы задание. Мы будем проводить расчеты на этой границе.
  • Давайте предположим, что после каждой попытки 5% процентов от сдающих разочаровываются и больше никогда не пытаются пересдать экзамен (сдаются): $p_{14} = p_{24} = 0,05$
  • Опыт увеличивает ваши шансы. Давайте предположим, что вероятность несдачи экзамена из состояния 2 на 30% меньше, чем из состояния 1: $p_{23} = p_{12} + (1 - p_{12})*0,3$
  • При этом упростим задачу и будем считать, что такое увеличение опыта происходит лишь один раз. Это предположение упростит расчет и не изменит наши выводы.
  • Также будем считать, что на свой первый экзамен 50% идет с нулевым знанием об экзамене (то есть из состояния 1) и 50% специально готовятся к технике сдачи экзамена (из состояния 2). При этом мы считаем, что их реальное, полезное знание и навыки приблизительно одинаковы.

Какой процент успешной сдачи будет из состояния 1?

Теперь вероятность сдачи будет лишь 36% против 50% в случае честного подхода.
Вероятность сдачи из состояния 2 55%.

Полный же граф будет выглядеть следующим образом:



Здесь вы можете найти доказательство
Рассмотрим следующую цепь Маркова:



Мы добавили вероятности переходов, выделенные пунктирными линиями: $p_{41} = p_{31} = p_{42} = p_{32} = 0,5$. Т.к. мы не исследуем вероятность нахождения в состояниях 3 и 4, и нас интересуют только состояния 1 и 2 и вероятности перехода ИЗ них, то этот несколько искусственный прием допустим в данном случае. Эти добавленные переходы отражают тот факт, что на экзамене постоянно присутствует одинаковое количество претендентов: сколько убыло (сдало/сдалось) столько и добавилось. При этом коэффициент 0,5 обеспечивает выполнение последнего условия:

Также будем считать, что на свой первый экзамен 50% идет с нулевым знанием об экзамене (то есть из состояния 1) и 50% специально готовятся к технике сдачи экзамена (из состояния 2).

Матрица перехода для такой цепи будет следующей

$ A = \begin{pmatrix} 0 & 0 & 0,50 & 0,50\\ 0,59 & 0,40 & 0,50 & 0,50\\ 0,36 & 0,55 & 0 & 0\\ 0,05 & 0,05 & 0 & 0\\ \end{pmatrix} $



При этом вероятности состояний мы будем представлять в виде вектора:

$ p = \begin{pmatrix}p_1\\p_2\\p_3\\p_4\\\end{pmatrix} $



Где $p_1, p_2, p_3, p_4$ вероятности нахождения в состоянии 1,2,3,4 и

$ p_1 + p_2+p_3+p_4 = 1 $



Легко увидеть, что данная цепь Маркова обладает свойством эргодичности: мы можем попасть в любое состояние из любого состояния за n ходов, например, за 2. Из этого следует, что при достаточно большом количестве переходов (сдач экзамена) наступает стационарный процесс.

Найдем вектор состояний, соответствующий стационарному процессу:

$ Ap = p $



То есть нам нужно найти собственный вектор, соответствующий собственному числу равному 1.

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

Для $\lambda = 1$ мы получаем следующий собственный вектор:

$ p = p_4\begin{pmatrix}\displaystyle\frac{400}{73}\\\displaystyle\frac{1060}{73}\\\displaystyle\frac{727}{73}\\1\\\end{pmatrix} $


$p_4$ находится из условия

$ p_1 + p_2+p_3+p_4 = 1 $



Но в нашем случае нас лишь интересует соотношение вероятностей состояний 1 и 2. Легко увидеть, что в процентах это соотношение:

  • доля людей на экзамене в состоянии 1: $\displaystyle\frac{400}{1060+400} \approx 0,27$
  • доля людей на экзамене в состоянии 2: $\displaystyle\frac{1060}{1060+400} \approx 0,73$

Таким образом в стационарном режиме на экзамене будут сидеть 27% без опыта (состояние 1) и 73% претендентов с опытом (состояние 2). Это дает вероятность сдачи:

$ 0,27 * 0,36 + 0,73*0,55 = 0,50 $

что находится в соответствии с нашим условием сложности экзамена.

Это значит, что все наши заданные условия выполнены.

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

Понятно, что при таком подходе, доля людей, пытающихся сдать честно будет уменьшаться, экзамен начинает усложняться (чтобы сохранилось условие 50%), что приводит к тому, что вероятность сдачи из состояния 1 становится все меньше и меньше.

И все-таки я считаю этот подход справедливым. Здесь нет нечестной конкуренции. Просто нужно понять, что нужно готовиться конкретно к экзамену. Без этого, даже обладая отличными знаниями, вероятность сдать тест невелика (но есть).

Теперь предположим, что есть дампы. Как изменится картина?

Дампы. Нечестная конкуренция


Теперь наша схема изменилась:



Появилось еще одно состояние Дампы. Это значит, что претендент может воспользоваться дампами экзамена, что даст ему 100% вероятность сдачи. Теперь давайте зададим конкретные условия.

  • По-прежнему будем считать, что вендор поддерживает сложность задания на таком уровне, чтобы в среднем не более 50% претендентов проходили бы этот экзамен (мы оговорили это выше).
  • Как и в предыдущем случае, считаем, что опыт уменьшает вероятность несдачи экзамена на 30%.
  • Немного изменим вероятности перехода в состояние 4. Давайте для идеалистов ($p_{14}$ ) увеличим этот коэффициент до 10%, для перехода $p_{24}$ оставим таким же, равным 5%. Это не сильно повлияет на результат, но это будет отражать тот факт, что шок от попытки сдать экзамен из состояния 1 будет достаточно большим (причины мы обсудим позже), и разумно предположить, что это будет чаще приводить к разочарованию.
  • Предположим, что изначально всего лишь 20% претендентов используют дамп. Распределение между состояниями 1 и 2 при первой попытке будем считать равным (по 40%).
  • Будем считать, что, если первая попытка (из состояния 1 или 2) оказалась неудачной, и претендент все же решил продолжать, то ровно половина из них воспользуется дампом: $p_{12} = p_{15}$ и $p_{25} = p_{22}$

Давайте посмотрим, как изменится картина. Вот решение:


Здесь вы можете найти доказательство
Как и в предыдущем примере рассмотрим эргодическую цепь Маркова



Мы добавили вероятности переходов, выделенные пунктирными линиями: $p_{41} = p_{31} = p_{42} = p_{32} = 0,4$ и $p_{45} = p_{35} = 0,2$. Логика такая же, как и в предыдущем случае. Таким образом мы возвращаем убывших претендентов и обеспечиваем следующее условие:

Предположим, что изначально лишь 20% претендентов используют дамп. Распределение между состояниями 1 и 2 при первой попытке будем считать равным (по 40%).

Матрица перехода для такой цепи будет следующей

$ A = \begin{pmatrix}0 & 0 & 0,40 & 0,40 & 0\\0,43 & 0,31 & 0,40 & 0,40 & 0\\0,05 & 0,34 & 0 & 0 & 1\\0,10 & 0,05 & 0 & 0 & 0\\0,42 & 0,30 & 0,20 & 0,20 & 0\\\end{pmatrix} $


Найдем вектор состояний, соответствующий стационарному процессу:

$ Ap = p $



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

Получим что для $\lambda = 1$ мы имеем следующий собственный вектор:

$ p \approx p_5\begin{pmatrix}0,649\\1,344\\1,489\\0,132\\ 1\end{pmatrix} $


$p_5$ при этом находится исходя из условия нормировки вероятности

$ p_1 + p_2 + p+3 + p_4 + p_5 = 1 $


но для решения нашей задачи, как и в предыдущем случае, в этом нет необходимости.

Найдем доли людей на экзамены в состояниях 1,2,5:

  • доля людей на экзамене в состоянии 1: $\displaystyle\frac{0,649}{0,649+1,344 + 1} \approx 0,22$
  • доля людей на экзамене в состоянии 2: $\displaystyle\frac{1,344}{0,649+1,344 + 1} \approx 0,45$
  • доля людей на экзамене в состоянии 5: $\displaystyle\frac{1}{0,649+1,344 + 1} \approx 0,33$

Таким образом видно, что доля сдавших экзамен будет:

$ 0,22*0,05 + 0,45*0,34 + 0,33 = 0,494\approx 0,5 $



То есть данное решение удовлетворяет всем нашим условиям.

Мы видим, что вероятность сдать экзамен из состояния 1 стала всего 5%, что значит, что у вас практически нет шансов. Казалось бы, что для состояния 2 все не так уж и плохо 34%, но, в действительности, при небольших значениях $p_{13}$ такой расчет $p_{23}$ не совсем корректен. Дело в том, что наше условие опыт уменьшает вероятность несдачи экзамена на 30% искусственно ограничивает снизу вероятность $p_{23}$ тридцатью процентами (ниже быть не может), что, конечно же, не совсем правильно

Единственный вывод, который пока можно сделать это то, что при наших условиях мы можем забыть про возможность сдачи из состояния 1 (нет опыта). Очень скоро комьюнити, для которого этот экзамен представляет интерес, осознаёт это, и количество идеалистов, пытающихся сдать экзамен без соответствующей подготовки, становится пренебрежимо малым. Тогда мы получаем другую диаграмму:



При тех же условиях, что и в предыдущем примере, мы получим следующее решение:



При этом распределение на экзамене будет следующим:

Состояние 1 (опыт): $\approx66$%
Состояние 2 (дамп): $\approx34$%

Думаю, что метод доказательства очевиден из предыдущих двух примеров, поэтому я опускаю его.

Это значит, что при появлении дампов (и при тех условиях, которые мы наложили) мы получим падение вероятности сдачи для людей, которые специально готовились к экзамену или имели опыт неудачной сдачи и при этом не используют дампы с 55% до 25%, то есть более чем в 2 раза.

Теперь давайте вспомни условия.
При первой попытке у нас лишь 20% решили сразу воспользоваться дампом. После неудачной попытки лишь половина решает воспользоваться дампом. И это довольно мягкое условие привело к тому, что для претендентов, готовящихся к экзамену без дампов, сдать экзамен становится очень сложно. В среднем им придется сдавать этот экзамен 4 раза. Затраты на подготовку (время) и на сдачу становятся довольно большими. При этом можно сдать по дампу. Это потребует существенно меньшего времени на подготовку и даст практически 100% вероятность сдачи.

Итак, давайте посмотрим на плюсы и минусы, которые получает претендент в обоих случаях.

Что имеют те, кто пытаются сдавать без дампов?

  • (-) потраченное время на подготовку (деньги)
  • (-) потраченные деньги за неудачные попытки
  • (-) в случае неудачи руководство и коллеги начинают сомневаться в их компетенции
  • (+) хороший уровень знания

Те, кто сдают с дампами

  • (-) стоимость дампа (необязательно: дамп может находиться в свободном доступе)
  • (-) возможно, недостаточный уровень знаний (необязательно: никто вам не мешает хорошо подготовиться при этом)
  • (-) морально-этические издержки, связанные с нечестной конкуренцией (необязательно и очень индивидуально)
  • (+) минимально потраченные ресурсы
  • (+) уважение коллег и руководства (ведь не обязательно говорить, что вы воспользовались дампом)

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

Когда цена дампа становится меньше цены честной сдачи, человек начинает пользоваться дампами.

Состояние насыщения


При низкой стоимости дампа это приводит к цепной реакции: чем больше людей пользуются дампами, тем сложнее становится экзамен и тем меньше вероятность сдать без дампов, что заставляет все большее количество людей прибегать к нечестной конкуренции, и в конце концов это приводит к ситуации насыщения, когда при первой попытке, количество претендентов, пользующихся дампами, уже превышает заданный проходной процент (50% в наших примерах).

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

Пример

Предположим, что экзамен меняется раз в 3 месяца, на появление нового актуального дампа уходит 2 недели, тогда вероятность сдачи с дампом падает со 100% до $\approx 85$%. Но этого может быть недостаточно, поэтому экзамен все усложняется и усложняется, появляются разные варианты, делается так, что даже с дампом требуется интенсивная тренировка.

Таким образом,

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

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

Пример

Таким экзаменом, на мой взгляд, до недавнего времени был CCIE R&S. Существуют прекрасные курсы для подготовки к CCIE, например, ine.com. Но, даже пройдя всю подготовку (что займет у вас около полугода, полностью потраченные на это), сдать экзамен все равно достаточно сложно. И параллельно с этим, во всяком случае еще несколько лет назад, вы легко могли найти бесплатные дампы в интернете, как письменных экзаменов, так и лабораторных работ.

Следствия


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

Вы удивитесь, на какие вопросы не отвечают счастливые обладатели CCIE сертификатов. Не редко эксперты совершенно не готовы к честному собеседованию. И дело не в том, что они когда-то знали, но забыли. Дело в том, что они этого никогда и не знали. Зачем учить, тратить время, деньги, рисковать, когда можно просто зазубрить ответы на вопросы.

Конечно же, это приводит к падению авторитета экспертных сертификатов. От этого страдают не только и не столько вендоры, сколько инженеры, которые получили данные регалии честно. Происходит нивелирование того конкурентного преимущества, которое давал добытый потом и кровью статус.

Думаю, многие из вас наблюдали такую картину: сильный инженер, с хорошим практическим опытом, внимательно изучив рекомендуемую литературу, идет сдавать экзамен и проваливает его. Он обескуражен. Вопросы кажутся не относящимися к делу (и это нередко так), тексты слишком большими и запутанными, часто претендент просто не укладывается во времени. При этом его коллега, с гораздо меньшим опытом и знанием, сдает этот тест практически на 100%. Это типичный результат нечестной конкуренции.

Дампы и вендоры


Почему же вендоры не защищают авторитет своих сертификатов? Может быть это невозможно или очень дорого?

Уверен, что это возможно, и мы видим это на примере CISSP.

Для этого нужно повышать стоимость дампа. И делать это можно следующими путями:

  • делать случайную выборку вопросов из гораздо большего списка, например, из 10000 вопросов
  • знание, которое претендент получает при честной подготовке должно быть действительно ценным для него (что уменьшает полную стоимость честного/справедливого подхода)
  • моральная-этическая составляющая цены дампа должна быть высокой. В комьюнити должно быть однозначное осуждение использования дампов
  • также обычно не представляет труда найти и запретить ресурсы, распространяющие дампы

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

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

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

Есть еще один хороший способ увеличить качество сертификата можно просто добавить собеседование.

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

Заключение


В данной статье мы рассмотрели несколько моделей, которые я назвал

  • честный подход
  • справедливый подход
  • нечестная конкуренция, дампы

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

Каждый из данных подходов накладывает определенные требования к подготовке. Честный подход требует только хорошего знания теории и хороших практических навыков. Справедливый подход требует также специфической подготовки к экзамену.

Случай нечестной конкуренции несколько сложнее, он включает в себя, например, морально-этическую составляющую, что непросто оценить. Но некоторые выводы мы все же можем сделать:

  • у вас практически нет шансов сдать экзамен честно (в контексте данной статьи это значит, что вы пытаетесь пройти тест, опираясь лишь на необходимое теоретическое знание и практический опыт, без специальной подготовки именно к технике сдачи экзамена)
  • нужно специально тренироваться для сдачи этого экзамена, но, чтобы сдать без дампов, ваш уровень должен быть очень высок, в действительности гораздо выше, чем разумное требование, соответствующее целям и смыслу этого экзамена
  • наличие и широко практикуемая нечестная конкуренция во многом лежит на совести вендоров. На мой взгляд, именно они обязаны защищать авторитет своих сертификатов. В этих условиях, думаю, сложно осуждать инженеров, пользующихся дампами. Иногда без них цена честной сдачи становится непомерно высока, а требования к знанию многократно завышены

Казалось бы, зачем играть в эти игры? Однозначно, что это нужно не всем, но есть несколько факторов, которые важны:

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

Для меня именно последний пункт всегда являлся самым важным, а сертификаты это приятные и иногда полезные бонусы!
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru