Угу. Потом для операции искривления придётся формулировать как «плоская фигура», потом как «поверхность»…

не брюзжите,.. кому сейчас легко?

А если класс параметризуется типом? Все прекрасно меняется.

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

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

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

Без лишних слов, объяснений на пальцах, ввода лишних терминов, а просто два определения.

состояние это внутреннее свойство обьекта. значение - проекция состояния наружу.

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

например - просто строка.

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

или нейронная сеть, которая генерит строки.

или алгоритм генерации случайной строки.

итак - значение одно, а внутренние состояния, определяемые реализацией - вполне себе различные.

итак - значение одно, а внутренние состояния, определяемые реализацией - вполне себе различные.

И никакой связи между ними нет. Так что писать про проекцию бессмысленно. См. свой же пример про объект «строка».

Операция std::cout << применима к любому объекту. И где тут формализм строгой типизации?

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

состояние это внутреннее свойство обьекта. значение - проекция состояния наружу.

Хотелось бы всё таки услышать определение от Djanik.

пример - есть класс строка. и метод value() возвращающий строку.

Я Вас прям не узнаю - всегда такой дотошный, а тут… Строка полиморфная или нет, value() - метод чего?

Строка полиморфная или нет, value() - метод чего?

лана назовем класс - SomeString, и у него метод value() возвращающий std::string к примеру. каким образом появляется эта строка результата - вы не знаете. состояние обьекта закрыто от вас. но значение вы знаете. это я имел ввиду

См. выше по треду, я дала определение понятия «состояние». Значением объекта может быть что угодно, но с состоянием может быть связано, а может нет.

См. выше по треду, я дала определение понятия «состояние». Значением объекта может быть что угодно, но с состоянием может быть связано, а может нет.

Вот это:

состояние у нее есть. состояние констант true и false класса boolean - разное.

Это значение, а не состояние, и не надо их путать.

А состоя́ние — понятие, обозначающее множество устойчивых значений переменных параметров объекта.

? Хм, ну ладно.

Чем значение объекта типа bool отличается от состояния объекта типа bool?

лана назовем класс - SomeString, и у него метод value() возвращающий std::string к примеру. каким образом появляется эта строка результата - вы не знаете. состояние обьекта закрыто от вас. но значение вы знаете. это я имел ввиду

Усложним. Добавляем std::string SomeString::value2() const. Что теперь будет называться значением объекта класса SomeString?

объект может оказаться в неопределенном состоянии

объект может оказаться в неопределенном состоянии

1. Вы таки не ответили на прямой вопрос
2. Будет ли у объекта в неопределенном состоянии значение?

ПыСы. Пока ещё в этом треде я не увидел строгого формального определения понятий «значение» и «состояние», такого которое бы позволило однозначно сказать «вот эта сущность есть значение, а вот эта - состояние», ни от кого.

Будет. Я же написала, состояние и значение могут совпадать, но это не обязательно.

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

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

Хорошо. Применимо ли к такому объекту понятие «значение» вообще? И если результат запроса обернут во что-то - это уже «состояние» или всё ещё «значение»? Или «значение» в принципе не применимо к compound objects? А как тогда быть с сущностями вроде std::complex?

Раз тут все такие вумные собрались, может по теме чего-нибудь накидаете?

Или «значение» в принципе не применимо к compound objects?

Вызов метода объекта возвращает значение или состояние.

std::vector - [] возвращает значение, empty, size - состояние.

Раз тут все такие вумные собрались, может по теме чего-нибудь накидаете?

Да дайте же развлечься то!

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

по теме чего-нибудь накидаете?

реализации кэша Least Recently Used

Для произвольно длинных потоков целых чисел найдите медиану элементов эффективным способом.

Лол. Я — соискатель, а не наниматель. Хочу подготовиться, блин.

Про медиану часто спрашивают.

То есть просто среднее значение в отсортированном ряду?

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

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

текущее состояние это точка в многомерном пространстве его возможных состояний.

два обьекта одного типа в одинаковом состоянии тождественны. а ваши состояния - соединен/не соединен - вовсе не говорит о тождестве.

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

два обьекта одного типа в одинаковом состоянии тождественны

С чего бы это? Каждый имеет свое соединение с бд, и размер очереди запросов, к примеру.

Каждый имеет свое соединение с бд, и размер очереди запросов, к примеру.

вы читать-то умеете? то, что вы называете «состоянием» потому им не является. потому что два обьекта находящиеся в одном вашем «состоянии» нетождественны совершенно.

как вы будете определять тождественность двух обьектов? или оно не надо?

А зачем им быть тождественными? Объекты инкапсулирующие fsm по определению нетождественны, т.к. их состояние определяется уникальной последовательностью переходов.

потому что два обьекта находящиеся в одном вашем «состоянии» нетождественны совершенно

Имеющие одно соединение БД и одну очередь на двоих? Наверное, тождественны. Но по построению у каждого своё соединение, поэтому никак.

Имеющие одно соединение БД и одну очередь на двоих? Наверное, тождественны. Но по построению у каждого своё соединение, поэтому никак.

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

Объекты инкапсулирующие fsm по определению нетождественны, т.к. их состояние определяется уникальной последовательностью переходов.

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

Имеющие одно соединение БД и одну очередь на двоих? Наверное, тождественны. Но по построению у каждого своё соединение, поэтому никак.

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

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

Хммм...

Рискну ответить. Хотя команда и стабильна вот уже чуть более 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, например?

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

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

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

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

общие базовые психологические установки, которые есть у отслуживших

Это какие, можно полюбопытствовать? И нахрен они человеку, который пришел работать программистом, а не в армии служить?

И нахрен они человеку, который пришел работать программистом, а не в армии служить?

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

Полюбопытствовать? Можно. =)))

Это какие, можно полюбопытствовать? И нахрен они человеку, который пришел работать программистом, а не в армии служить?

Только я сомневаюсь что Вы (лично Вы) выдержите ответ, если я сформулирую его в привычном для себя стиле. Так что… постараюсь как-нибудь помягче. =))) Кстати, в «привычном стиле» разговариваю не только я. И, слава Богу, у нас не ЛОР, ни кто не покарает. Но это мелочи.

Понимаете, Вы сейчас явно показали именно то, о чём я и говорю – Вы задали ненужный вопрос. Не всегда нужно «думать», «задавать вопросы» или что-нибудь в этом роде. Иногда нужно просто исполнять. Выполнять требования, заложенные в Т.З. без идиотских рассуждений «а я думаю…», точно и в срок. В таких случаях самое мягкое что Вы бы услышали в ответ, это «всё, что Вы думаете, Вы можете распечатать на бумажке, свернуть в трубочку и загнать себе туда, куда у нормальных людей Солнце не заглядывает, при чём с такой силой, чтоб через зубы вышло».

Услышали бы Вы это один раз. Второй такой же залёт и… Вот чтобы не увольнять, я и не нанимаю. =)))

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

Скрам это скрам. Есть требования, есть задачи на ближайшие две недели, результат будьте любезны показать. Нет, мне пофиг чем Вы там занимаетесь в остальное время. Если гениальны, то напишите код, спаяйте железку или что там у Вас в задачах выставлено хоть за 15 минут, хоть в Тае или на Гоа. Мне пофиг. Реально. Но вот за мелкие подставы и меня лично и команды в целом, я урою. Лично.

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

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

Постарался мягко. =)))

Десантёры лучше.

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

Проверено. =))) А ещё лучше выпускники соотв. профильных ВУЗов. Если ещё и послужить успел, то вообще чума. Такого уже не испугать дедлайном. Он и так знает откуда просто ветер дует, а откуда хрен летит…

P.S. Поэтому команда и жива вот уже более 10 лет. И неплохо себя чувствует в современных реалиях. Игроки-то все… командные. =)))

Да ты дядя, душный мудак.

когда я был начальник, я отбирал иначе.

1. выявление наличия технарских мозгов. то есть рациональное, техническое мышление.
2. огонь в глазах, то есть реальный интерес к делу.
3. опыт не столь важен. в 90 проц. случаев проще и лучше научить, чем переучивать. а «люди с опытом» страдают в голове тараканами и лишними комплексами из прошлого. с такими как раз труднее работать.
4. требовать наличия знаний, что можно получить за два дня чтения доков, нет смысла.
5. армейский опыт во внимание не принимается.
6. ну.. и чтобы человек был хороший..

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

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

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

Нет никаких проблем на ретро сказать из-за чего произошёл перерасход времени…

Но видимо в своём ответе вы показали ваше место между вами и менеджерами.

Во-во... Почти попали!

Остановлюсь на нескольких пунктах из перечисленного. То, что совпадает или не совпадает с моим мировоззрением (вспоминая Паркинсона – любая компания реализует комплекс неврозов её руководителя).

огонь в глазах, то есть реальный интерес к делу.

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

опыт не столь важен. в 90 проц. случаев проще и лучше научить, чем переучивать. а «люди с опытом» страдают в голове тараканами и лишними комплексами из прошлого. с такими как раз труднее работать.

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

армейский опыт во внимание не принимается.

Всегда должно быть то, о чём как правило на гражданке забывают. Персональная ответственность. Всегда должно быть с кого конкретно спросить.

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

ну.. и чтобы человек был хороший..

Это не специальность. Ни в трудовой книжке, ни в резюме об этом ничего нет. =))) Я проверял.

Это не специальность. Ни в трудовой книжке, ни в резюме об этом ничего нет. =))) Я проверял.

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

Между командой и заказчиками?

Но видимо в своём ответе вы показали ваше место между вами и менеджерами.

Как я понимаю, Вы это хотели сказать. Да, с Заказчиками мне и приходится обычно общаться, нанимать третьих лиц чтобы они болванчиками сидели и кивали головами на совещаниях это в моём понимании плодить лишних людей. «Колхоз 70 лет без урожая», он же «Месть Ильича», слышали? Вот мне лень это разводить. Да и денег жаль.

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

И

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

В составлении Т.З. принимают участие и Заказчики и исполнители. И нет смысла рвать на голой заднице волосы клочьями и голыми руками, уверяя что мы всё забабахаем на счёт раз и за месяц, если там работы на год.

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

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

Этап написания Т.З. это самое удобное время, поверьте. Если Т.З. требует дополнений, то отдельным документом. Но к работе не приступаем пока Т.З. не утрясено. Иначе эта работа может не один год продлиться. Проверено. «А мы тут подумали…» вызывает ответ – «любой каприз за ваши деньги».

У меня нет в команде мальчиков для битья. Хотите списать на них косяки в ваших требованиях изначально – ищите мальчиков в другом месте.

Либо меня и команду уважают и относятся с пониманием, либо я и понимать не должен.

Нет никаких проблем на ретро сказать из-за чего произошёл перерасход времени…

Оггада… Вот только всегда есть тот, кто допустил косяк. Валить на неведомого стрелочника при таких подходах не получается. Стрелочники извините, но на станции.

Мне проще.

Я сам начальство. А вот «примадонн» сразу за борт. Ещё на собесе. В том-то и суть что таких чижиков отравленных надо вычислять сразу. И не взирая на заслуги перед Родиной гнать ссаными тряпками из команды. Не им создана – не ему и рушить. Он тут явно не для того.

И зачем это может понадобиться в эмбедщине

Хотя команда и стабильна вот уже чуть более 10 лет

прикована цепью к батарее в подвале? :P

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

Я Вас понял.

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

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

Самым лучшим было бы просто дать человеку возможность поработать. Люди вокруг (мои коллеги) тоже так относятся. Все мы косячим. Вопрос – будет ли сам человек искать свои косяки и их исправлять. Отношение к делу, я бы так сказал. Вот это для меня первично.

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

Собесы же к сожалению, судя по тому что я слышу изредка, напоминают что-то типа такого – собеседующий чего-то новенькое для себя выучил ли вычитал в инторнетах этих ваших и теперь вновь обретённым знанием мозг рушит собеседуемому. Смысл? Зачем?

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

Типа копирования элементов друг в друга без tmp, указателями через XOR или какие-то конкретные задачи.

Just write in C. It’s enough.

методичку деда из армии,

Да, есть такое. =))) Но я тут Суворова поцитировал малость, напомню Лермонтова – «полковник наш рождён был хватом, слуга Царю отец солдатам». За своих парней тоже надо уметь горло рвать, а не делать вид что ты менеджер и не при делах, дескать, они плохие а я тут сбоку постоял, типа покурить вышел. Среди гражданских такой подход сплошь и рядом.

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

За своих парней тоже надо уметь горло рвать, а не делать вид что ты менеджер и не при делах

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