Здравствуйте, Handie, Вы писали:

H>2)
H>

H>void reverse(char *string)
H>{
H>  char *p1= string;
H>  char *p2 = string + strlen(string) -1 ;
H>  while(p1<p2) {
H>     char tmp = *p1;
H>     *p1= *p2++;
H>     *p2++ = tmp;
H>  }
H>}
H>

Здравствуйте, Abyx, Вы писали:

A>тогда лучше сразу спросить от чего зависит,
A>или *как рассчитывается* — max(sizeof(int), default_align) + default_align (хотя хз чем это знать IRL)
Как рассчитывается — мне по фигу. Интересно, знает ли соискатель о выравнивании, о том что на разных платформах размер будет разным...

A>для атомарности — есть <atomic>,
только в c++11
A>а volatile, это так, вспомогательное средство чтоб гарантировать что в памяти всегда лежит самое свежее значение переменной, при помощи которого можно написать atomic типы
а при чем тут вообще атомик? В эмбеддинге через volatile обычно регистры ввода-вывода объявляют...

E>>>>*(unsigned*)(buf+5)=123456;
A>>>вы уже уволили того кто так написал?
E>>встречный вопрос — почему его надо уволить?
A>за char[] и магическое число 5 вместо структуры с читабельным названием и именами полей
Насчет char[] — не соглашусь. Если выплевывать этот буфер наружу — проще char с вполне четким расположением в памяти, чем структура, с которой надо обращаться крайне аккуратно и окружать прагмами.
А вообще то на таком коде можно схватить аппаратное исключение из-за невыровненного доступа...

E>>встречный вопрос — а если нет с++11?
A>а это звоночек
Вполне нормальная ситуация. Кто ж обновит сильно платный компилер ради с++11

A>т.е. вопрос в том как спроектировать фреймворк для передачи данных по разным протоколам? ответ сильно зависит от структуры пакетов и требований по производительности.
A>это может быть либо AbstractDeviceFacade+AbstractXXXFacade с виртальными методами на каждый пакет, либо свободные функции и структуры на каждый пакет — вариантов много
Вполне себе тема для обсуждения...

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

Спасибо, хорошая идея, надо подумать...

Здравствуйте, Vzhyk, Вы писали:

>> У Страуструпа в белой книжке есть ответы почти на все эти вопросы,
>> буквально на первых 100-150 страницах.
V>Именно. Но в этом-то и ловушка подобных собеседований, в которую себя
V>загоняют работодатели, а потом плачут, что вот взяли весь такой красивый
V>на собеседовании, а делать нехера не хочет.

так базу в любом случае нужно знать
для embeded C++ вопросы абсолютно адекватные, и очень простые. если человек этого не знает, то вряд ли он подойдёт даже на должность "делать нехера не хочет"

Здравствуйте, enji, Вы писали:

E>Здравствуйте, Abyx, Вы писали:

A>>если кандидат может ответить на остальные вопросы — строку он как-то развернет наверное
E>ок, выкидаем

не надо выкидывать, маленький алгоритм всё равно нужно давать.
программисты должны уметь их писать. если не умеют писать маленькие алгоритмы(например как этот http://www.rsdn.ru/forum/job/4875854.1.aspx

Автор: Handie
Дата: 31.08.12

), то что вообще может получится на задаче побольше?

31.08.2012 17:17, Piko пишет:

> так базу в любом случае нужно знать
Надо. Но это лучше выяснить, беседуя с человеком о том, что именно он и
как делал.

> для embeded C++ вопросы абсолютно адекватные, и очень простые. если
> человек этого не знает, то вряд ли он подойдёт даже на должность "делать
> нехера не хочет"
Вопросы выше, скажем так, скользкие в массе своей. И самого то главного
и не выясняют, будет ли человек работать.

Но, если не важна работа, то годится. Но, каждый ССЗБ .

Здравствуйте, enji, Вы писали:

E>>>>>*(unsigned*)(buf+5)=123456;
A>>>>вы уже уволили того кто так написал?
E>>>встречный вопрос — почему его надо уволить?
A>>за char[] и магическое число 5 вместо структуры с читабельным названием и именами полей
E>Насчет char[] — не соглашусь. Если выплевывать этот буфер наружу — проще char с вполне четким расположением в памяти, чем структура, с которой надо обращаться крайне аккуратно и окружать прагмами.
не понял насчет расположения в памяти. типа явное смещение 5 лучще чем структура?
так если хочется чтобы в коде было явное число 5, то лучше юзать структуру, и написать static_assert(offsetof(Foo, bar) == 5, "invalid offset");

E>А вообще то на таком коде можно схватить аппаратное исключение из-за невыровненного доступа...
а была бы структура — компилятор увидел бы невыровненное смещение, и сгенерил бы нужный код
хотя мне почему-то кажется что и в случае с buf+5 компилятор должен увидеть смещение. зависит от компилятора конечно.

Здравствуйте, Vzhyk, Вы писали:

>> так базу в любом случае нужно знать
V>Надо. Но это лучше выяснить, беседуя с человеком о том, что именно он и
V>как делал.

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

>> для embeded C++ вопросы абсолютно адекватные, и очень простые. если
>> человек этого не знает, то вряд ли он подойдёт даже на должность "делать
>> нехера не хочет"
V>Вопросы выше, скажем так, скользкие в массе своей. И самого то главного
V>и не выясняют, будет ли человек работать.

ещё раз, эти несколько вопросов прощупывают знание базы (обязательной!), не более не менее

V>Но, если не важна работа, то годится. Но, каждый ССЗБ .

кто сказал что не важна?
ты думаешь топикстартер даже не собирался беседовать с кандидатом?
lol

Здравствуйте, enji, Вы писали:

S>>Сколько вы готовы заплатить за выполнение "домашнего задания"?
E>А за что тут платить?
За трату времени.

Здравствуйте, enji, Вы писали:

E>Ну ок, собираем статистику.
E>30% — ханди, сисентер, os24ever — попрощался
Меня тоже добавляй. Попросить примеры кода — ещё нормально. Любого, если говорит что нету — можно попросить набросать пример и предложить в качестве тематики то, что ты предлагаешь в виде тестового задания.

E>т.е как минимум с 50-60% соискателей я найду понимание. С 30% — не найду

ИМХО тестовое задание стоит сделать в трёх случаях: много свободного времени, интересное задание и очень хочется попасть в именно эту контору.

Здравствуйте, enji, Вы писали:

Не сишник, но если интересно, могу высказать свое ИМХО.

E>Рассказать о будущей работе, ответить на вопросы (~5-10 мин)
E>Спросить о прошлом опыте, если он есть — поговорить поподробней о каких-то решениях, их последствиях (~5-10 мин)

Я бы не стал четко определять время на это. Пункты выше — самое главное в собеседовании. Им стоит уделить максимум внимания. В разговоре лучше всего виден уровень знаний и способность думать.
А вот дальше я бы, как минимум, разделил примерный ход собеседования на минимум 2 градации: начинающий, но толковый(бестолкового уже можно провожать), или опытный. Потому как вопросы ниже вызовут зевоту у опытного.

Ну и по самим вопросам:

E>Несколько простых вопросов на знание языка (~15-20 мин):
E>- напишите функцию реверса строки

[зевает]

E>- чему равен размер struct {int a; char c;}

Может у некоторых вызвать подозрение собеседующего в некомпетенции(я же надеюсь, вы не скажете, что на этот вопрос есть точный ответ?).

E>- зачем нужен volatile

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

E>-
E>

E>char buf[20]={0}; 
E>*(unsigned*)(buf+5)=123456;
E>

E>чем чревато, как лучше?

Доктор, а откуда у вас такие картинки? Уж не придется ли мне это говно на работе разгребать?

E>- #define MAX(a,b) — как написать, чем чревато?

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

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

Про второй вопрос — хз, много лет на плюсах не писал. Но его постановка отчего-то сильно попахивает вариантом, что тут все криво, и вообще говнокодом.

E>- Есть устройство, у которого могут быть разные каналы передачи данных (посл порт, tcp, twi, ...) и разные протоколы (отличаются форматом пакетов). Как бы вы спроектировали программу для него?

Норм.

E>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
E>И оценить как работу проги (написать простой автотестер, который скормит кривые пакеты, случайный мусор, а также правильные команды и посмотрит на ответы), так и исходный код, наличие тестов, сборочного скрипта, репозитария dvcs

Несмотря на то, что задание вроде бы и несложное(я надеюсь, протокол-то хоть простой? А то бывают и многоуровневые с хитрым шифрованием, проверкой целостности и нетривиальными алгоритмами обработки ошибок для возвращения в рабочее состояние, это уже не лезет ни в какие ворота), я бы отказался писать. Мне даже банально влом было бы дома настраивать девелоперское окружение(это иногда занимает совершенно не то время, которое ожидается

Автор: Eugeny__
Дата: 07.05.10

). Ну и вообще, задачка похожа уж сильно на реальную . Как бы я это сделал, на словах бы рассказал. А писать — нене, у меня в графике таких как вы много, и тестовые нужны одной конторе из 10 в лучшем случае. Хотя не знаю, как у вас там в городе дела обстоят.

Здравствуйте, enji, Вы писали:

E>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."

Плохая задача. Она очень муторная в обработке ошибок. Различные обрывы (и восстановления) связи с устройством, расхождения в контрольной сумме и прочие радости. Включая необходимость переотправки в некоторых случаях пакета с хоста (по таймауту).

Выделенное особенно плохо. Откуда вы такое вообще берете? Правильным в данном случае будет жестко закодировать обработку этих ваших 4-5 команд в код. Добавление новых команд делается либо типичными кейсами теми же (если случаи простые). Либо написанием нормальной инфраструктуры тогда, когда она понадобится (а мало ли, там на какую-то команду потребуется совсем другой обмен, например). Какие-то куски будут использованы из начального решения, но общая архитектура может сильно поменяться. Нужно хотя бы десяток команд. Лучше — десятка полтора-два. И из разных "аспектов" работы устройства. На практике обычно известно, что за устройство используется, и можно предполагать, что оно умеет делать. А также можно предполагать, что оно точно не умеет делать, и это не менее важно! И если вы хотите увидеть здесь стратегии — вы можете их не увидеть. Решение с простейшим case/if'ами тоже прекрасно поддерживается и сопровождается. А вот со стратегиями могут быть сложности (например, найти, где они инициализируются и т.п.). Нет, они тоже могут быть, но нужно понимать, с какой именно целью и куда они добавляются.

Здравствуйте, Abyx, Вы писали:

E>>Насчет char[] — не соглашусь. Если выплевывать этот буфер наружу — проще char с вполне четким расположением в памяти, чем структура, с которой надо обращаться крайне аккуратно и окружать прагмами.
A>не понял насчет расположения в памяти. типа явное смещение 5 лучще чем структура?
Да, иногда лучше. В массиве char[] четко видно смещение 5. В структуре его не видно — надо складывать размеры всех предыдущих членов. Структуру надо окружать прагмами. Кроме того, есть bigendian, что добавляет гемора со структурами. Еще есть битовые поля — надо помнить правила их расположения, они кстати тоже зависят от big/little-endian
Также некоторые части пакета могут быть с нефиксированной длиной. Я даже не знаю, как это выразить структурой...

Мое решение — если мест формирования таких пакетов много — написать что-то вроде

struct SomePacket {
  byte buf[1500];
  void set_cmd(int c) { memset(buf+5, &cmd, 3); }
  void set_flag1(bool f) { put_bit(buf+127, 7, f); }
  ....
}

Если же пакет формируется ровно в одном месте, то никаких доп струтур не заводить и формировать его прямо в коде.

Здравствуйте, Трололоша, Вы писали:


E>>А за что тут платить?
Т>За трату времени.

Не всякая трата времени оплачивается.
ты посетил собеседование, потратил время, но тебе за него не заплатили

Здравствуйте, Трололоша, Вы писали:

Т>Здравствуйте, enji, Вы писали:

E>>Ну ок, собираем статистику.
E>>30% — ханди, сисентер, os24ever — попрощался
Т>Меня тоже добавляй. Попросить примеры кода — ещё нормально. Любого, если говорит что нету — можно попросить набросать пример и предложить в качестве тематики то, что ты предлагаешь в виде тестового задания.

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

Здравствуйте, maxkar, Вы писали:

M>Здравствуйте, enji, Вы писали:

E>>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."

M>Плохая задача. Она очень муторная в обработке ошибок. Различные обрывы (и восстановления) связи с устройством, расхождения в контрольной сумме и прочие радости. Включая необходимость переотправки в некоторых случаях пакета с хоста (по таймауту).

Тут как ты понимаешь, все зависит от протокола. Если протокол простой (как тот, что я имел в виду), то там все просто. CRC там обычный xor, обрыв связи устройство не колышит, протокол вида запрос-ответ, накладывается на обычную стейт-машину.

M>Выделенное особенно плохо. Откуда вы такое вообще берете? ....

Опять таки все зависит от протокола. В данном конкретном достаточно таблицы команда — функция-обработчик
Если реализовать ее не в виде switch, то можно будет добавлять новые команды динамически — например в зависимости от конфигурации. Или на одном хоботе поддерживать одни команды, а на другом — другие.

E>>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."

M>Плохая задача. Она очень муторная в обработке ошибок. Различные обрывы (и восстановления) связи с устройством, расхождения в контрольной сумме и прочие радости. Включая необходимость переотправки в некоторых случаях пакета с хоста (по таймауту).

Может я чего-то не понимаю, но ИМХО такие вещи надо делать генератором в ДКА. Описание в json/xml/yaml и генератор кода на питоне + утильный функционал писаный на кондовом С. И никаких радостей, всё скучно и однотипно.

Здравствуйте, Eugeny__, Вы писали:

E__>А вот дальше я бы, как минимум, разделил примерный ход собеседования на минимум 2 градации: начинающий, но толковый(бестолкового уже можно провожать), или опытный. Потому как вопросы ниже вызовут зевоту у опытного.

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

E__>Несмотря на то, что задание вроде бы и несложное(я надеюсь, протокол-то хоть простой? А то бывают и многоуровневые с хитрым шифрованием, проверкой целостности и нетривиальными алгоритмами обработки ошибок для возвращения в рабочее состояние, это уже не лезет ни в какие ворота), я бы отказался писать.

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

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Может я чего-то не понимаю, но ИМХО такие вещи надо делать генератором в ДКА. Описание в json/xml/yaml и генератор кода на питоне + утильный функционал писаный на кондовом С. И никаких радостей, всё скучно и однотипно.

Гм. Наверное зависит от задачи. Если состояния 2-3-4-5 то возни с твоим генератором будет на порядки больше.

AS>>Может я чего-то не понимаю, но ИМХО такие вещи надо делать генератором в ДКА. Описание в json/xml/yaml и генератор кода на питоне + утильный функционал писаный на кондовом С. И никаких радостей, всё скучно и однотипно.

E>Гм. Наверное зависит от задачи. Если состояния 2-3-4-5 то возни с твоим генератором будет на порядки больше.

Команд или состояний? Очевидно что если команд пять, то при сетевом обмене состояний в несколько раз больше. Но однако сие вопрос практики и тех нескольких команд которые надо добавить. О них же как бы заранее не известно. Как бы понятно, что логика состоит из типового применения утильного кода, а вся веселуха заключается в корректном протаскивании и пакетов в нужном порядке и обработки всяких ножидонностей. Мы же типа говорим не про сделать шоб запустилось, а про демонстрацию профессионального подхода и навыков. Не?

Здравствуйте, Handie, Вы писали:

H>2)

H>void reverse(char *string)
H>{
H>  char *p1= string;
H>  char *p2 = string + strlen(string) -1 ;
H>  while(p1<p2) {

UB при пустой входной строке. Сравнение на больше/меньше указателей, не указывающих в один и тот же массив.