Что должен знать джун в 2024. Памятка к техсобесу
Спросили опытных айтишников, которые собеседуют молодёжь.
Спросили опытных айтишников, которые собеседуют молодёжь.
Сёння хачу чытаць па-беларуску
Условия в ИТ всё меньше напоминают оазис, особенно на входе. Мест для джунов в этом суровом ландшафте так мало, что работу получают только лучшие. Спросили айтишников, которые проводят собесы (и подсмотрели у компаний), каких знаний и умений они ждут от кандидатов:
Специальность: тестировщик
Кто говорит: QA Lead в Catalogic Software
— Наш продукт диктует специфические требования, но, кажется, эти знания для джуна не будут лишними.
Универсальные:
Теория тестирования. Джун должен знать, когда используются тест-кейсы, а когда лучше использовать чек-листы. Как работать с требованиями. Как составить баг-репорт.
Docker. Понимать, в чём разница между контейнером и образом. Как запустить/остановить контейнер.
REST API. Знать коды ответов (1хх, 2хх,3хх,4хх,5хх) и что они означают; привести несколько примеров кодов ответов (404, 403, 401, 200, 500, 301).
Знать как минимум четыре популярных API-метода: GET, POST, PUT, DELETE.
Уметь в Postman или Swagger.
Специфические (для нашей компании):
Linux. Джун должен знать как пользоваться этой операционной системой, переходит между директориями, включать выключать сервисы, как работают права на операционной системе.
Гипервизор. Базовые вещи: как создать и поставить виртуальную машину, как настроить виртуальную машину, как поставить операционную систему. Файловые системы: какие бывают, преимущества разных файловых систем.
Специальность: Data Engineer
Кто говорит: Data Engineer, опыт 4 года, проводит техсобесы
— В целом требования для 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, параллелизме и конкурентности, парадигмам ООП.
Всё на базовом уровне.
Специальность: разработчик на Android
Кто советует: компания Kolesa Group (для Junior 1)
Computer Science
Data Structures
— Знать Collections и Map;
— Знать распространенные реализации;
— Понимать в каких случаях нужны коллекции.
Programming Principles
— DRY;
— KISS.
OOP
— Знать основную идею ООП;
— Уметь перечислять все принципы с кратким описанием.
Architecture
— Делегирование;
— MVC.
Network
— Уметь работать с сетью любым способом.
Android Platform
Android SDK
— Знать структуру проекта;
— Знать, как открывать экраны и взаимодействовать с пользовательским интерфейсом;
— Знать Manifest и компоненты, которые там перечисляются;
— Знать, как пользоваться ресурсами и стилями.
Android Component
— Знать Activity и Fragment;
— Знать lifecycle и особенности использования.
UI
— Уметь верстать простой дизайн в xml;
— Знать ресурсы.
Threading
— Знать про существование многопоточного кода;
— Thread vs Process.
Test
— Уметь писать простые unit-тесты.
Tools
— Уметь пользоваться логами.
Memory Management
Memory structure
— Знать отличия между типами памяти (оперативная и постоянная).
GC
— Знать, что в Java не надо руками собирать мусор, и всё на этом :)
Language
Java & Kotlin
— Знать синтаксис;
— Соблюдать code style.
Специальность: разработчик на iOS
Кто советует: Kolesa Group (Junior 1)
Computer Science
Data
- Знать Collections и Map;
- Знать распространенные реализации;
- Понимать, в каких случаях нужны коллекции.
OOP
- Знать основную идею ООП;
- Уметь перечислять все принципы с кратким описанием.
Programming
- DRY;
- KISS.
Architecture
- Делегирование
- MVC
Network
- Уметь работать с сетью любым способом
iOS Platform
iOS SDK + 3rd
- App lifecycle;
- UIViewController lifecycle;
UI
- Уметь верстать простой дизайн в xib;
- Autolayout.
Threading
- Знать про существование многопоточного кода;
- Thread vs Process.
Tests
- Уметь писать простые unit-тесты.
Tools
- Уметь пользоваться логами.
Xcode
- Знать структуру проекта;
- Знать как открывать экраны и взаимодействовать с пользовательским интерфейсом;
- Breakpoints
- LLDB.
Memory Management
Memory
- Знать отличия между типами памяти (оперативная и постоянная).
ARC
- Знать, что в Swift не надо руками собирать мусор, и всё на этом :)
Language
Swift
- Знать синтаксис, типы;
- Соблюдать code style.
«Пот и слёзы». Джунов уже в 4 раза меньше! Выжившие делятся секретами
«Пот и слёзы». Джунов уже в 4 раза меньше! Выжившие делятся секретами
Бешеная конкуренция, зп от 400$. Как выглядит ИТ в Минске — рассказывает джун-джавист
Бешеная конкуренция, зп от 400$. Как выглядит ИТ в Минске — рассказывает джун-джавист
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Без предлагаемой вилки, все это довольно таки бесполезно. Если, к примеру, за это все 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