Што мусіць знаць джун у 2024. Памятка да тэхсумоўя
Спыталі дасведчаных айцішнікаў, якія сумовяць моладзь.
Спыталі дасведчаных айцішнікаў, якія сумовяць моладзь.
Умовы ў ІТ усё менш нагадваюць аазіс, асабліва на ўваходзе. Месцаў для джуноў у гэтым суровым ландшафце так мала, што працу атрымліваюць толькі найлепшыя. Спыталі айцішнікаў, якія праводзяць сумоўі (і падгледзелі ў кампаній), якіх ведаў і ўменняў яны чакаюць ад кандыдатаў:
— Наш прадукт дыктуе спецыфічныя патрабаванні, але, здаецца, гэтыя веды для джуна не будуць лішнімі.
Тэорыя тэсціравання. Джун мусіць ведаць, калі выкарыстоўваюцца тэст-кейсы, а калі лепш выкарыстоўваць чэк-лісты. Як працаваць з патрабаваннямі. Як скласці баг-рэпорт.
Docker. Разумець, у чым розніца паміж кантэйнерам і вобразам. Як запусціць/спыніць кантэйнер.
REST API. Знаць коды адказаў (1хх, 2хх, 3хх, 4хх, 5хх) і што яны азначаюць; прывесці некалькі прыкладаў кодаў адказаў (404, 403, 401, 200, 500, 301).
Знаць як мінімум чатыры папулярныя API-метады: GET, POST, PUT, DELETE.
Умець у Postman або Swagger.
Linux. Джун мусіць ведаць, як карыстацца гэтай аперацыйнай сістэмай, пераходзіць паміж дырэкторыямі, уключаць/выключаць сэрвісы, як працуюць правы на аперацыйнай сістэме.
Гіпервізар. Базавыя рэчы: як стварыць і паставіць віртуальную машыну, як наладзіць віртуальную машыну, як паставіць аперацыйную сістэму. Файлавыя сістэмы: якія бываюць, перавагі розных файлавых сістэм.
— У цэлым патрабаванні для Junior Data Engineer тычацца перш за ўсё тэхналогій, якія кандыдат мусіць знаць на базавым узроўні.
Абавязкова пытаем:
— Тыпы даных;
— Структура даных;
— Фізічнае захоўванне даных у БД;
— Адрозненні БД (калоначныя, малыя, NoSQL і асаблівасці працы рухавіка кожнай з іх);
— Алгарытмы, але не на суперглыбокім узроўні. Пытаемся пра кампрэсійныя алгарытмы, дзе якія выкарыстоўваюцца.;
— Фарматы файлаў для захоўвання вялікіх даных (Parquet, Avro і г. д.);
— OLAP vs OLTP;
— Data Lake, DWH, Data Vault 2.0, Data Mesh;
— Apache Airflow;
— Spark (асаблівасці працы з Java і Python API, калі кандыдат знае Scala — то і з ім таксама);
— Databricks і для чаго ён патрэбны;
— Azure, GCP або AWS стак, але яго адсутнасць некрытычная.
— Python. Веды наконт працы GIL, паралелізму і канкурэнтнасці, парадыгмаў ААП.
Усё на базавым узроўні.
Data Structures
— Знаць Collections і Map;
— Знаць распаўсюджаныя рэалізацыі;
— Разумець, у якіх выпадках патрэбныя калекцыі.
Programming Principles
— DRY;
— KISS.
OOP
— Знаць асноўную ідэю ААП;
— Умець пералічваць усе прынцыпы з кароткім апісаннем.
Architecture
— Дэлегаванне;
— MVC.
Network
— Умець працаваць з сеткай любым спосабам.
Android SDK
— Знаць структуру праекта;
— Ведаць, як адкрываць экраны і ўзаемадзейнічаць з карыстальніцкім інтэрфейсам;
— Знаць Manifest і кампаненты, якія там пералічваюцца;
— Ведаць, як карыстацца рэсурсамі і стылямі.
Android Component
— Знаць Activity і Fragment;
— Знаць lifecycle і асаблівасці выкарыстання.
UI
— Умець вярстаць просты дызайн у xml;
— Знаць рэсурсы.
Threading
— Ведаць пра існаванне шматпаточнага кода;
— Thread vs Process.
Test
— Умець пісаць простыя unit-тэсты.
Tools
— Умець карыстацца логамі.
— Знаць адрозненні паміж тыпамі памяці (аператыўная і пастаянная).
GC
— Ведаць, што ў Java не трэба рукамі збіраць смецце, і ўсё на гэтым :)
Java & Kotlin
— Знаць сінтаксіс;
— Выконваць code style.
Data
OOP
Programming
Architecture
Network
iOS SDK + 3rd
UI
Threading
Tests
Tools
Xcode
Memory
ARC
Swift
Рэлацыраваліся? Цяпер вы можаце каментаваць без верыфікацыі акаўнта.
Без предлагаемой вилки, все это довольно таки бесполезно. Если, к примеру, за это все Kolesa Group предлагает 200-400, то к ним и пойдут те, кто хочет проскочить на авось. Если они предлагают за это 600-1200, то да, тогда норм требования.
Embedded \ True embedded:
С, C++, любой из *nix на уровне домашнего администратора, принципы RTOS, общее понимание сетей tcp/ip, udp, понимание что такое протокол транспортного и прикладного уровня, знать хотябы назначение нескольких протоколов прикладного уровня (не http), работа со структурами данных сохранение, чтение, передача по сети (в бинарном виде), что такое memory leak и как с ним бороться, типы памяти процесса, little\big endian, gdb, gnu make, cross сборка, что такое линковка, что такое shared library, git
Карыстальнік адрэдагаваў каментарый 24 мая 2024, 00:37
Всегда хотелось попробовать себя в этой области - поближе к низкому уровню, - но не давало покоя отсутствие глубоких знаний в электронике.
Буду признателен, если сориентируете:
Можно ли начать без них, имея только представление о том, как работают процессор, память, операционная система, сеть (OSI). Какие проекты в embedded сейчас наиболее "голодные" с т.з найма ? контроллеры для робототехники, IoT, медицинская техника или только а-ля ТВ-приставки/телевизоры ?
Я бы не стал по этому поводу переживать. Смотрите. Во первых вы идёте как software разработчик. От вас в первую очередь нужны именно эти навыки. Конечно знание электроники вам облегчат жизнь особенно после первого года, когда столкнётесь с поиском причины почему что-то не работает а причиной является электроника а не software. Суть в том что если вы попадёте в такую компанию то там будет целый отдел занимающийся электроникой и они сертифицированы. Как правило это люди не понимающие software, и вам знание электроники облегчит процесс доказать им что проблема у них. Но если вы только пришли как junior вы столкнётесь с этим ну через год где-то.
Как junior - да. Вполне. Но давайте обратим внимание на ваш текущий опыт. Сколько лет и в какой области? Это важно, я как-то писал о том как у нас происходит. Могут пропустить просто по причине не релевантности. Тут есть решение, ввязаться в какой открытый проект. В скором времени (где-то месяц) я запускаю один свой открытый по reverse engineering, у редакции есть мои контакты, можете запросить (для редакции: разрешаю дать), присоединяйтесь, у вас появится релевантный опыт + если будет получаться возможно даже моя рекомендация. Если локации совпадают то вероятно интервью.
Это правда. Найти человека что называется plug and play очень сложно. Кругом вебня, а некоторые изобретают на собеседовании такие инопланетные технологии что спасает только медицинская маска чтобы кандидат не видел в какой гримасе скривился рот.
А вот обучать часто дорого. Кушать они хотят как в отрасли сразу, а делать начинают что-то ощутимое в лучшем случае через год.
Их огромное количество. Моя отрасль automotive.
Если ещё есть что спросить - спрашивайте или тут или через редакцию напрямую. Может упустил что.
Карыстальнік адрэдагаваў каментарый 24 мая 2024, 18:17
Спасибо !
А вот наверное что забыл.
Ну тут смотрите. Есть RTOS, туда попадут скорее всего робототехника, медицинская. Есть ebedded os (чаще linux, может быть embedded rtos) туда пойдут IoT, TV приставки, телевизоры. И есть то что называют как true embedded (возникло из за того что в эмбедед уже пихают всё что нипопадя), Так вот если мы говорим про например engine, transmission, VCU (Vehicle control unit) - это уже будет true embedded. Как таковой OS там нет, нет как такового runtime, нет динамической памяти. Там сам принцип памяти организован иначе. Если брать мою отрась, то там представлен весь спектр и даже комбинированные решения на tricore, это когда несколько разновидностей крутятся на одном физическом контроллере. Например комбинация RTOS + embedded os, или true embedded + что-то.
Например встречал true embedded как гипервизор + free rtos
Как-то так.
Карыстальнік адрэдагаваў каментарый 24 мая 2024, 22:57
Сейчас у меня в приоритете робототехника и UAV/eVTOL, хотя медтехника - тоже интересное направление, и спрос на специалистов виден.
Мой бэкграунт - машиностроение, в т.ч робототехника. Хочется "на старости лет" перейти в работу с системами управления - от контроллера до computer vision, т.е. оставить создание исполнительных устройств в качестве хобби. Связка C++/Python/Linux нравилась всегда, но писать доводилось только "поделки" на уровне самоучки для различного рода расчетов и моделирования динамики. Т.е. я - не профессиональный программист даже близко; только читаю пока Хоровица + Хилла, Таненбаума.
Полагаю, если и заходить в эту отрасль, в моем случае лучше начать с уровня RTOS, и, если в компании будут открыты к этому, углубляться true embedded, уже давая ценность на уровне выше.
Так или иначе, благодрю за развернутые ответы.
План в принципе не плохой. Но если опыта программирования мало на том-же Linux, лучше его потянуть а из RTOS взять понимание основ и несколько простых примеров потом сделать которые наглядно покажут в чём разница между обычной ОС и RTOS. Дело в том что в обычных условиях для обычной программы не будет заметно разницы. Да и для человека. Просто поставьте ядро с RT в Linux и попользуйтесь. Принципиальной разницы вы не увидете, да и не должны. Далеко не везде будет видна эта разница. Можете поиграть с разными примерами в linux на обычном ядре и ядре с RT. Если вы найдёте эту разницу и поймёте её, можно считать что у вас уже хорошие практические знания. К сожалению таких людей не много сейчас свободно гуляет, разобрали, мне приходилось иметь дело с теми у кого чисто академические и даже дело с теми у кого их не было. Так что если у вас будут на собеседовании практические примеры разницы я бы сразу взял на мидла. И думаю так большинство и поступит. Этот сектор не укомплектован специалистами. Без работы не останетесь.
Карыстальнік адрэдагаваў каментарый 25 мая 2024, 00:09
Благодарю за подсказку снова.
Возможно, этот путь (через понимание фундаментальной разници между "жесткими", "мягкими" RT и "гражданскими" OS) - именно тот, который приведет в новую роль
P.S.
Надеюсь, не злоупотребляю вашим вниманием.
Упустил сразу: на начальном этапе знание C (malloc, пр.) принципиально или можно зайти с C++ ?
Встречал противоречивые мнения. С одной стороны, C lang- фундамент многих решений до сих пор, бережливое использование памяти, быстродействие, "хардкор" без высокоуровневых абстракций из коробки. С другой, C++ проникают все глубже к железу, и, возможно, уже не так важно, сколько килобайт памяти съедает код, если не страдают надежность, бвстродействие, а скорость разработки и удобство обслуживания ПО растут.
Я понимаю, что C все еще считается подмножеством C++, но, все же, это, скороее, множества существенно пересекающиеся. Более того, стиль написания, концепции разные. В общем, "слышу звон, но не знаю где он" пока
Карыстальнік адрэдагаваў каментарый 25 мая 2024, 01:17
Крайне желательно. Но если у вас RTOS то не обязательно, там C++ больше нужен чем чистый С
Тут вот какая штука, если доберётесь до true embedded то там нужен будет C. К сожалению не все контроллеры потянут C++. И дело не в памяти. Пример. Bosch RC 28\30 Вполне кушал C++ и это было здорово. А вот RC-40 уже нет. И дело не в памяти, делов том что у них просто нет людей которые могут правильно прописать распределение памяти для vtable. Ведь для этого нужно куда-то часть кода положить. Они просто не вытянули и там только чистый C. С++ он конечно кушает, но как только появляется хоть одна виртуальная функция компилятор просто не знает куда её положить. Воюю уже второй год чтобы мне дали схему и я сам пропишу. Но пока увы.
Так что по вашему плану вам С++ даже лучше. Но в true embedded понадобиться
Карыстальнік адрэдагаваў каментарый 27 мая 2024, 19:57
Здесь вы совершенно правы. У меня например есть 46 видов техники и большая часть кода у них одна. C++ делает это на ура. На С тоже решаемо. Но факт в том что код уже написан на плюсах, переносить это всё сейчас на С будет не просто. По сути надо всё переписывать либо давить поставщека чтобы либо открыл спецификации либо доделал сам.
Мне в сущьности всё равно что там начальство решит. Я одинаково хорошо плаваю как в С так и в С++
Карыстальнік адрэдагаваў каментарый 27 мая 2024, 20:05
— Azure, GCP или AWS стек, но его отсутствие некритично. - для девелоперов это не критично, дата инженер обязан знать базис, для девопсии это библия, желательно все три, или хотя бы два из них
...по факту требования по теории к junior и senior соискателям одинаковы, вроде так всегда было.
Data Engineer с 4 годами опытами походу спрашивает больше, чем знает сам.
Нефундаментальные (привязанные к библиотеками и фреймворкам) вопросы, построенные на опыте собеседующего, зачастую говорят об узости кругозора собеседующего.
Во время собеседования лучше выяснять не то, что кандидат НЕ знает из опыта собеседующего, а что и как он знает из своего опыта. Если то, с чем кандидат работал, он знает достаточно глубоко (и может понятно это донести) - то аналогичного уровня погружения и коммуникации можно ожидать от него при работе с любой другой технологией.
Но такой подход является неподъёмным для большинства собеседующих, так как переносит их из сильной позиции "расскажи мне то, что я знаю" в слабую "нужно оценивать то, чего я возможно не знаю".
Карыстальнік адрэдагаваў каментарый 24 мая 2024, 12:48