Вот уже третий день в твиттере срутся по поводу треда про тестовые задания в Nokia:
https://twitter.com/st_1ena/status/1419689924505260032
Особенно многих удивила озвученная там зарплата (в 2018 году) — предлагали 120 тысяч рублей в месяц. Народ поделился примерно на два лагеря — первые считают, что задания простые, решит любой студент, и с чего бы это студенту платить больше? Вторые — в основном это успешные фронтендеры, у которых единицей измерения зарплаты служит «1 козуля» (вроде бы 300 тысяч рублей в месяц) считают задачи адски сложными, критерии оценки дикими, ну а озвученную зарплату нищенской. Срутся уже три дня, смотреть на это весело.
Сегодня за обедом начал писать «ответ» — тредик о том, что вас ждет после такого собеседования, какие задачки придется решать после его прохождения, и почему все написанное в том треде — реально важно и нужно?
Спойлер — основано на личном опыте ощупывания большого телекомовского слона, к Нокии отношения не имеет, YMMV.
Для начала вспомним модель OSI, которая, как всем известно, не существует. Когда ее упрощают до четырехслойной — то руководствуются простой логикой, все, что ниже IP (то бишь сетевого уровня) — это херня какая-то, проводочки, не заслуживающие внимания. На самом деле там адов зоопарк, от «понятных» и привычных проводного Ethernet и живущего в вашем роутере WiFi до всякой редкой хтони типа 6LoWPAN. Это, кстати, два разных уровня — упрощенно их можно обозвать MAC (medium access control) и PHY (physical); стандарт Ethernet описывает, грубо, один вариант MAC поверх нескольких PHY, WiFi — несколько связок MAC+PHY, 6LoWPAN — один LLC и MAC поверх полутора десятков PHY из IEEE 802.15.4 и даже Bluetooth. PHY — это отдельная песня, а мы сейчас посмотрим на уровень MAC. Издеваться над людьми я не хочу, так что в качестве учебного протокола уровня MAC в современной беспроводной сети возьмем LoRaWAN.
Ну я думаю, вы все ознакомились со стандартом LoRaWAN? Он небольшой, всего-то сотня страничек — так что давайте продолжим. Стандарт — это хорошо, это надежно, можно (теоретически) набрать толпу программистов и начать делать оборудование под этот стандарт. Потом, правда, возникнут вопросы — например, очевидный: LoRa (физический уровень) поддерживает несколько скоростей передачи данных. В LoRaWAN есть механизм ADR, Automatic data rate, с помощью которого сетевой сервер может назначить конечному устройству какую-то скорость.
Вопрос попроще: а как бы нам эту скорость определить правильно? Побольше? Проиграем в дальности (а LoRa — это Long Range, что намекает). Поменьше? Начнутся коллизии при передаче, проиграем в емкости сети (это сколько устройств можно повесить на одну «точку доступа»). Стандарт этот вопрос почти никак не комментирует, предлагая всегда использовать наибольшую скорость из возможных (определяя ее по SNR, например). Но у модуляции LoRa есть очень интересное свойство — передача данных с использованием разных data rate ортогональна. Это значит, что если одно устройство передает данные, допустим, с DR5, а другое — с DR4 — то шлюз примет данные от обоих! И возникает вопрос посложнее — а как назначать data rate устройствам, чтобы максимально использовать вот этот бесплатный бонус?
Уже звучат вопросы — так какие же задачи придется решать после того зверского собеседования в Нокию? Нет, не такие. Вопрос на самом деле уже решен — немного в другой постановке, но идея довольно понятна (если вы осилите 20 страниц настоящего «матана«). Ноучная ноука в виде Евгения Хорова из ИППИ РАН с соавторами понаписала формул, порисовала графиков — и с точки зрения науки, все хорошо, план по публикациям выполнен, можно спать спокойно.
На самом деле между такого рода «академической» наукой и программистами у любого более-менее крупного вендора есть еще прослойка в виде толпы математиков-алгоритмистов (я тут осознанно упрощаю реальное взаимодействие между всеми заинтересованными сторонами — это не так важно), которые должны выцеплять вот такие хорошие идеи, независимо их проверять и дальше передавать программистам. Разумеется, не все так безоблачно — 95% публикаций будет полным говном, неприменимым в реальной жизни — но в принципе, на то эти математики и нужны, чтобы склепать из оставшихся 5% что-то теоретически удобоваримое. «Удобоваримое» — это еще оптимистично, математики на выходе генерят обычно псевдо- или говнокод на ебучих языках типа питона или матлаба; могут выдать полный пиздец на том, что им кажется C++, или просто на отъебись хуйнуть блок-схему:
Не правда ли, все просто и понятно? Попизжено, кстати, вот отсюда: https://arxiv.org/pdf/2010.08860.pdf, это тоже творчество Хорова сотоварищи, но довольно близко к тому, что попадет в руки программистам.
И вот в этот момент бедному программисту, прорвавшемуся через ад собеседований в условную Нокию, сваливается задание, состоящее из обрывков стандарта (написан наркоманами из IEEE или какого-нибудь еще комитета во время коллективного прихода) и дополнений к нему, написанных математиками, живого радиомодема не нюхавшими.
Мне так жалко программиста стало, что пойду за пивком схожу.
Пока я за пивком еще не пошел — пизданул тут на днях, что сетевой сервер LoRaWAN можно утоптать ногами в жирный микроконтроллер (хотя таких прецедентов я не знаю) — и мне похуй, спизданул и спизданул, а для руководителя вашего проекта это стало руководством к действию!
Я вернулся, принял пивка, продолжим.
Что проверяют те нокиевские задания и что мы увидим в нашем проекте охуительного сетевого сервера LoRaWAN по цене простого тупого шлюза? Да собственно все то же самое — манипуляции с битиками? Открываем стандарт и смотрим на любой заголовок MAC-уровня. Манипуляции с самописной реализацией половины коллекций из stdlib? Этого в эмбеде полно, кушайте, не обляпайтесь. Если хотите рассказать, как вам в жизни помогает знание std::list — посмотрите на любое scatter-gather DMA и представьте, что это очередь пакетов, которые будут запихиваться в радиомодем «по готовности». Нет, вы не обернете её в привычный список — а манипулировать очередью надо! Что еще? Задачи с неясной изначально постановкой, про которые надо либо спросить, либо додумать? И этого тут предостаточно, посмотрите хотя бы на это произведение математического мозга:
Ученый (в говне моченый) написал «Sort groups by $PLR_g^{QoS}$» (да, именно так и написал) — а ты теперь сам думай, в какую структуру обернуть эти «группы» и как после этого их эффективно отсортировать. Ах да, учоные на словах еще сообщили, что лучше всего этот алгоритм выполнять «как можно чаще» :)
Математиков этот вопрос не волнует — они готовы даже показать симуляционную модель, где сортируют std::list<std::map<std::string, std::list<SomeShit>>> — в типичном случае эта штука займет всю доступную память в вашем устройстве.
И это, считайте, вам еще повезло — потому что ваш коллега вынужден реализовывать сок мозга другого математика, который молодец, читал Кормена и даже может там ткнуть пальцем в алгоритм Хопкрофта-Карпа (поиск паросочетания в двудольном графе). Вы даже можете найти эту штуку в википедии, но она вам не поможет — это еще более ебаный псевдокод, чем напечатан у Кормена. Что вы там говорили по поводу «адаптации алгоритмов, которые сто раз уже реализованы»?
Ну и да, не забываем, что все эти красивости происходят на микроконтроллере, пусть и жирном, с целым МЕГАБАЙТОМ оперативной памяти — а вам надо будет еще упихнуть туда целый TCP/IP стек, возможно, даже готовый — что-то вроде lwIP, но даже от этого не легче. Остается утешать себя тем, что вам досталась простая и понятная вещь — потому что старый стандарт того же WiFi, 802.11-2012 — это 2800 страниц, вот такая упаковка бумаги и еще полпачки:
Я кончил и закурил.
