История изменений

Рискну ответить. Хотя команда и стабильна вот уже чуть более 10 лет и нет, я ни кого не ищу, но всё же спрашивал бы немного по-другому.

Собственно, до того, как я начал бы спрашивать по теме embedded, я бы постарался понять что за человек передо мной и как он вольётся (и вольётся ли) в команду. Собственно, если надо «валить» спеца, который пришёл на собес, то валить его на этом этапе надо.

У меня и в доковидные времена не было офиса и сейчас нет и в принципе не будет. Так что, почти 10 лет у нас сразу «удалёнка». Отсюда и морально-психологические черты, на которые я сразу смотрю. Не важно – пришёл бы человек «с улицы» или по рекомендациям.

1. Гражданство. Только Россия, нет, не обсуждается. С «кодерашу за еду» это не ко мне, точно.

2. Наличие образования и/или срока службы в армии. Нет? Мимо. Вопрос – «а пачиму, ведь нормальные спецы есть и среди гражданских…» вызывает ответ – «да патаму». Да есть, не спорю, но мне нужны некие общие базовые психологические установки, которые есть у отслуживших. Разбираться с чьими-то тараканами в голове, от «заходов» которых у моих, в моей башке возникают бурные овации, плавно переходящие в истерику в зале, это лишнее. У коллег вызывать такие же проблемы – вдвойне на фиг.

3. Сколько кандидат хочет денег? Если сразу топчик по рынку, то уже сомнения. Человек ещё не показал результатов, ни строки кода, нет участия в завершённых наших проектах, т.е., мне он ни копейки не принёс, а уже хочет сразу и много. Сомневаюсь я чего-то. Либо это «примадонна» и спец, которых десяток на всю Россию, либо ему лучше бы сразу урезать осетра и сформулировать как-то вот так – «начнём со среднерыночной, а дальше уже посмотрим». Вот такой подход я бы понял. Мне не нужны рабы, мне нужны люди, адекватно оценивающие реалии.

4. Отношение к критике и к жизни в целом. Политические пристрастия. Если раздаётся обычное «всё вокруг… они там…» то это сразу нет. Либо не знаю, не интересовался (тогда кадра надо дальше вентилировать), либо «мне пофиг, я своей жизнью живу» (а вот это наш человек, т.к. умеет трезво смотреть на жизнь и брать на себя ответственность).

Отношения к критике так же важно. У каждого из нас за спиной есть своё «кладбище» проектов. Что помешало довести проекты до успеха и где сам судак? Ну либо пусть код покажет из того, что не под NDA или пет-проекта. Посмотрим как отнесётся к тому, как его малость попинают. Не сильно, но тут важно определить границы психоустойчивости. Нет, писать код на собесе ненужно. И не факт что напишет из-за стресса и код в проде будет написан этим кандидатом в более спокойном состоянии. Т.е., это сразу получится более качественный код. Учитывая то, что мы говорим о суммах за работу не в 20Р/час, то косяки вылезут практически сразу.

Как кандидат отнесётся к тому, что на первое время, пока вкуривает что и к чему, у него будет «дедушка»? =))) Ментор? Либо человек сразу понимает что этот ментор позволит ему как можно быстрее втянуться и тащить, либо сразу в обидки кинется. Последнее сразу лесом.

5. Если мой коллега, предполагаемый ментор просто качнёт головой типа «нет», то сразу нет. Отказ. Причины буду выяснять в последнюю очередь, т.к. психоздоровье команды важнее.

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

Теперь по техническим вопросам.

1. Ненужно освещать все дальние и глухие уголки стандарта. Надо уметь думать и знать где посмотреть. «Всё знать» невозможно. Но хоть знать для человека механизмы адресации в сети нужно. И хотя бы примерно представлять себе структуру пакета. Как его перехватить (libpcap), как его сгенерировать (скрафтить – libnet или ещё аналоги). Будет ли RAW-socket обрабатываться файерволлом в Linux (нет, не будет, т.к. обработка RAW это на совести приложения, использующего такие сокеты, к системе можно не лезть).

Ну и т.д. и т.п. Специфику тоже учитываем. Например, я всецело согласен с уважаемым monk в том, что ненужно кидаться писать hash, если есть такая возможность. Да, в glibc есть и hsearch() и tsearch(). До кучи можно ещё упомянуть GLib, там ещё много чего есть. Но в embedded не всегда возможно использовать эти жирные либы, если мы в bare metal, например.

Человек должен иметь практическое представление о «большом О» и методах оценки применимости алгоритмов. В конце-концов, ADT уже давно изобрели и algoritms & interfaces человек должен уметь применять. Идеально, если у человека есть своя либа для таких случаев и мы можем пообсуждать применяемые подходы. Например, нужна ли именно либа или можно на макросах справиться? Ещё раз – мы не про 20р. в час говорим, а о человеке, у которого есть опыт.

2. Шины, интерфейсы. Когда какую лучше? Хоть примерно? Варианты реализации. Если человек называет библиотеку, то понимаем, что он как-то про неё хотя бы слышал/использовал её.

3. Какие методы по обеспечению безопасности исходного кода он знает и что применял? Я не ожидаю что у человека по умолчанию включён syntastic & splint в vim, но хоть про отличия статического анализа от valgrind он слышал же? Как лучше выставить опции компилятора? Какие? FORTIFY_SOURCE, -Werror, ещё какие опции знает, например, для контроля срыва стека или контроля форматных строк?

4. Про С/С++. Нет, это плохо, когда кандидат смешивает эти языки. Несмотря на то, что С++ изначально создан был как прекомпилятор CFront к С, с тех пор утекло много воды. И С++ это семантически другой язык. Нет, весь трешак про «состояния» из данного треда мимо, т.к. на деле мы имеем дело только с состояниями процессора и больше ни с какими. Т.е., есть адреса, значения, регистры, прерывания. Если человек видит вычислительную систему таким образом, то есть о чём говорить. Если он не понимает что член класса это не более чем «адрес», содержащий нечто, то лучше не продолжать. Иначе придётся долго разжёвывать что стандарт C++ не предписывает, как на самом деле реализуются указатель на член класса, но общая стратегия заключается в том, чтобы он хранил смещение в байтах от основания объекта к рассматриваемому полю. Как правило. Т.е., у нас всегда есть либо просто адрес, либо адрес-смещение. И адрес это про железо в итоге, если что. Так что, несмотря на то, что С++ позволяет спуститься по уровням абстракции вниз и до железа, С здесь в разы проще и позволяет создавать предсказуемо работающее ПО. Сразу. Просто отслеживаем или изменяем состояния системы. Какой и сколькиразрядной, это не важно. gcc позволяет компилировать и линковать через ld бинари практически для всех возможных архитектур.

Вдобавок хотелось бы узнать как именно парадигмы программирования (ООП, ФП) связаны с языками программирования? Ответ – ни как. Реализация той или иной парадигмы это просто вариант записи кода, понятный программисту. Компилятор один чёрт переведёт его в понятный процессору.

5. Знакомство с ассемблерами, дизассемблерами отладчиками. Очевидно.

6. Знакомство с виртуальными машинами и вариантами кросскомпиляции. Может ли кандидат сам подготовить себе виртуалку и работать в ней с кодом? Любопытства ради – сколько вариантов виртуализации и сколько вариантов контейнеризации кандидат может назвать на вскидку? Нужен toolchain (кстати, что это) под Aarch64, Ваши действия? Полезли на linaro? Ещё варианты? crossdev, например?

На самом деле, вопросов намного больше, но общий вектор, если бы я проводил собес, был бы такой. Смысла валить кандидата нет. Всё равно он будет подтягиваться и вливаться. Вопрос только сможет ли, не окажется ли его багаж знаний настолько унылым, что он просто половины из обсуждаемого в рабочем порядке понимать не будет. Если не будет понимать о чём речь, да ещё и шипы не к месту будет выпускать, то он на фиг не нужен. Проще сразу сказать «извините, к сожалению, Вы нам не подходите» чем тянуть кота за тестикулы.

Мы все продаёмся и все покупаемся, важно только цену платить/запрашивать адекватную реалиям.

Рискну ответить. Хотя команда и стабильна вот уже чуть более 10 лет и нет, я ни кого не ищу, но всё же спрашивал бы немного по-другому.

Собственно, до того, как я начал бы спрашивать по теме embedded, я бы постарался понять что за человек передо мной и как он вольётся (и вольётся ли) в команду. Собственно, если надо «валить» спеца, который пришёл на собес, то валить его на этом этапе надо.

У меня и в доковидные времена не было офиса и сейчас нет и в принципе не будет. Так что, почти 10 лет у нас сразу «удалёнка». Отсюда и морально-психологические черты, на которые я сразу смотрю. Не важно – пришёл бы человек «с улицы» или по рекомендациям.

1. Гражданство. Только Россия, нет, не обсуждается. С «кодерашу за еду» это не ко мне, точно.

2. Наличие образования и/или срока службы в армии. Нет? Мимо. Вопрос – «а пачиму, ведь нормальные спецы есть и среди гражданских…» вызывает ответ – «да патаму». Да есть, не спорю, но мне нужны некие общие базовые психологические установки, которые есть у отслуживших. Разбираться с чьими-то тараканами в голове, от «заходов» которых у моих, в моей башке возникают бурные овации, плавно переходящие в истерику в зале, это лишнее. У коллег вызывать такие же проблемы – вдвойне на фиг.

3. Сколько кандидат хочет денег? Если сразу топчик по рынку, то уже сомнения. Человек ещё не показал результатов, ни строки кода, нет участия в завершённых наших проектах, т.е., мне он ни копейки не принёс, а уже хочет сразу и много. Сомневаюсь я чего-то. Либо это «примадонна» и спец, которых десяток на всю Россию, либо ему лучше бы сразу урезать осетра и сформулировать как-то вот так – «начнём со среднерыночной, а дальше уже посмотрим». Вот такой подход я бы понял. Мне не нужны рабы, мне нужны люди, адекватно оценивающие реалии.

4. Отношение к критике и к жизни в целом. Политические пристрастия. Если раздаётся обычное «всё вокруг… они там…» то это сразу нет. Либо не знаю, не интересовался (тогда кадра надо дальше вентилировать), либо «мне пофиг, я своей жизнью живу» (а вот это наш человек, т.к. умеет трезво смотреть на жизнь и брать на себя ответственность).

Отношения к критике так же важно. У каждого из нас за спиной есть своё «кладбище» проектов. Что помешало довести проекты до успеха и где сам судак? Ну либо пусть код покажет из того, что не под NDA или пет-проекта. Посмотрим как отнесётся к тому, как его малость попинают. Не сильно, но тут важно определить границы психоустойчивости. Нет, писать код на собесе ненужно. И не факт что напишет из-за стресса и код в проде будет написан этим кандидатом в более спокойном состоянии. Т.е., это сразу получится более качественный код. Учитывая то, что мы говорим о суммах за работу не в 20Р/час, то косяки вылезут практически сразу.

Как кандидат отнесётся к тому, что на первое время, пока вкуривает что и к чему, у него будет «дедушка»? =))) Ментор? Либо человек сразу понимает что этот ментор позволит ему как можно быстрее втянуться и тащить, либо сразу в обидки кинется. Последнее сразу лесом.

5. Если мой коллега, предполагаемый ментор просто качнёт головой типа «нет», то сразу нет. Отказ. Причины буду выяснять в последнюю очередь, т.к. психоздоровье команды важнее.

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

Теперь по техническим вопросам.

1. Ненужно освещать все дальние и глухие уголки стандарта. Надо уметь думать и знать где посмотреть. «Всё знать» невозможно. Но хоть знать для человека механизмы адресации в сети нужно. И хотя бы примерно представлять себе структуру пакета. Как его перехватить (libpcap), как его сгенерировать (скрафтить – libnet или ещё аналоги). Будет ли RAW-socket обрабатываться файерволлом в Linux (нет, не будет, т.к. обработка RAW это на совести приложения, использующего такие сокеты, к системе можно не лезть).

Ну и т.д. и т.п. Специфику тоже учитываем. Например, я всецело согласен с уважаемым monk в том, что ненужно кидаться писать hash, если есть такая возможность. Да, в glibc есть и hsearch() и tsearch(). До кучи можно ещё упомянуть GLib, там ещё много чего нет. Но в embedded не всегда возможно использовать эти жирные либы, если мы в bare metal, например.

Человек должен иметь практическое представление о «большом О» и методах оценки применимости алгоритмов. В конце-концов, ADT уже давно изобрели и algoritms & interfaces человек должен уметь применять. Идеально, если у человека есть своя либа для таких случаев и мы можем пообсуждать применяемые подходы. Например, нужна ли именно либа или можно на макросах справиться? Ещё раз – мы не про 20р. в час говорим, а о человеке, у которого есть опыт.

2. Шины, интерфейсы. Когда какую лучше? Хоть примерно? Варианты реализации. Если человек называет библиотеку, то понимаем, что он как-то про неё хотя бы слышал/использовал её.

3. Какие методы по обеспечению безопасности исходного кода он знает и что применял? Я не ожидаю что у человека по умолчанию включён syntastic & splint в vim, но хоть про отличия статического анализа от valgrind он слышал же? Как лучше выставить опции компилятора? Какие? FORTIFY_SOURCE, -Werror, ещё какие опции знает, например, для контроля срыва стека или контроля форматных строк?

4. Про С/С++. Нет, это плохо, когда кандидат смешивает эти языки. Несмотря на то, что С++ изначально создан был как прекомпилятор CFront к С, с тех пор утекло много воды. И С++ это семантически другой язык. Нет, весь трешак про «состояния» из данного треда мимо, т.к. на деле мы имеем дело только с состояниями процессора и больше ни с какими. Т.е., есть адреса, значения, регистры, прерывания. Если человек видит вычислительную систему таким образом, то есть о чём говорить. Если он не понимает что член класса это не более чем «адрес», содержащий нечто, то лучше не продолжать. Иначе придётся долго разжёвывать что стандарт C++ не предписывает, как на самом деле реализуются указатель на член класса, но общая стратегия заключается в том, чтобы он хранил смещение в байтах от основания объекта к рассматриваемому полю. Как правило. Т.е., у нас всегда есть либо просто адрес, либо адрес-смещение. И адрес это про железо в итоге, если что. Так что, несмотря на то, что С++ позволяет спуститься по уровням абстракции вниз и до железа, С здесь в разы проще и позволяет создавать предсказуемо работающее ПО. Сразу. Просто отслеживаем или изменяем состояния системы. Какой и сколькиразрядной, это не важно. gcc позволяет компилировать и линковать через ld бинари практически для всех возможных архитектур.

Вдобавок хотелось бы узнать как именно парадигмы программирования (ООП, ФП) связаны с языками программирования? Ответ – ни как. Реализация той или иной парадигмы это просто вариант записи кода, понятный программисту. Компилятор один чёрт переведёт его в понятный процессору.

5. Знакомство с ассемблерами, дизассемблерами отладчиками. Очевидно.

6. Знакомство с виртуальными машинами и вариантами кросскомпиляции. Может ли кандидат сам подготовить себе виртуалку и работать в ней с кодом? Любопытства ради – сколько вариантов виртуализации и сколько вариантов контейнеризации кандидат может назвать на вскидку? Нужен toolchain (кстати, что это) под Aarch64, Ваши действия? Полезли на linaro? Ещё варианты? crossdev, например?

На самом деле, вопросов намного больше, но общий вектор, если бы я проводил собес, был бы такой. Смысла валить кандидата нет. Всё равно он будет подтягиваться и вливаться. Вопрос только сможет ли, не окажется ли его багаж знаний настолько унылым, что он просто половины из обсуждаемого в рабочем порядке понимать не будет. Если не будет понимать о чём речь, да ещё и шипы не к месту будет выпускать, то он на фиг не нужен. Проще сразу сказать «извините, к сожалению, Вы нам не подходите» чем тянуть кота за тестикулы.

Мы все продаёмся и все покупаемся, важно только цену платить/запрашивать адекватную реалиям.