Спрошу совета и поступлю по-своему

[spamsink]

На следующей неделе мне нужно будет интервьюировать очередного кандидата в наладчики (НЕ разработчики). Меня попросили уделить внимание теме "thinking like a programmer", безотносительно к языкам и алгоритмам, так как разработческого уровня знания языков и алгоритмов от наладчиков не требуется, но мышление они должны иметь подтянутое и молодцеватое. Я другой методы думанья не знаю, и потому нахожусь в некотором недоумении, как это проверять, не пользуясь известными инструментами.

Что посоветуете? Только, пожалуйста, не надо про жирафа и холодильник!

Comments

[raydac.livejournal.com]

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

[spamsink]

Речь не об уровне, а о стиле мышления.

[raydac.livejournal.com]

тогда получается можно ему дать какуюнить ТРИЗовскую задачу, например про отбраковку шариков для подшипников

[spamsink]

Это интересно, но ведь тризовских задач им решать не придется, так зачем мучить?

[fatoff.livejournal.com]

А вот как он себе представляет игру 15 в компутере? Отставим в сторону графический интерфейс, одну абстракцию двигания клеток. Ну, массивы-то в колледже на программировании проходил, навереное.

[spamsink]

Не совсем понимаю, в чем вопрос.

[fatoff.livejournal.com]

Вопрос не к тебе, а к кандидату на позицию наладчика: "Как бы вы запрограммировали поле для игры в '15'?" Если не знает, что за игра, объяснить. Квадратное поле, 4x4, 15 перемещаемых фишек-цифер, каждая из которых занимает одну ячейку из 16. Цифры идут от 1 до 15. Изначально цифры расположены хаотически, задача в том, чтобы составить их по порядку слева направо сверху вних.

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

Три уровня "thinking like a programmer".

[vitus_wagner]

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

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

[archaicos.livejournal.com]

Гады, монету зажали.

[spamsink]

Если вы не знаете другого стиля мышления, значит вы просто не считаете другие стили мышлением.

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

[vitus_wagner]

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

[archaicos.livejournal.com]

Чего налаживать-то? Маслом смазывать?

[spamsink]

Эмуляцию дизайна, обычно на Верилоге, с применением I/O транзакторов на Си.

[sab123.livejournal.com]

А какое место в ней налаживают?

[spamsink]

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

[sab123.livejournal.com]

Тогда не видно разницы с разработчиком.

[spamsink]

Наладчику не нужно разрабатывать никакую новую функциональность.

[sab123.livejournal.com]

Если оно сравнимо с портированием, то получается, что надо.

[spamsink]

Там скорее работа, больше подобная тестеру. Запустить, найти ошибку, локализовать, доложить, получить patch build, смыть (make clean), повторить.

[no more turtles (from livejournal.com)]

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

[spamsink]

Существенная часть умений наладчика находится в сфере языков описания аппаратуры; процесс наладки в некоторой степени схож с работой тестировщика, с той разницей, что от наладчика требуется не умение придумывать тесты, а умение минимизировать примеры, воспроизводящие ошибки, проявившиеся на данных заказчика, что в общем случае нетривиально, и по возможности придумать способы обхода ошибок (собственно, именно для этого и нужно "программистское мышление", а не только умение разглядывать диаграммы сигналов). Вероятность, что наладчику придется залезть в сишный код упомянутых I/O, довольно мала. В общем, похоже, что правильнее будет проверять не столько программистское, сколько кюейное мышление.

[no more turtles (from livejournal.com)]

Ну тогда наверное лучше сделать такое тестовое задание, которое ближе всего к описанным задачам. Взять конкретный пример из практики и упростиь его так, чтобы можно было решить минут за 10. И поговорить о решении на интервью. А по результатам разговора составить субьективное впечатление. Если человек белеет или покрывается потом при виде такого примера, то он и в реальности врядли справится. А все остальные абстрактные задачи типа как сортировать пузырьком или что выдаст на отдельном взятом языке какая-то из пальца высосанная строка -- они "помогают" найти специалистов в решении только таких же дурацких задач. Потом эти специалисты оказывается или двух строк связать не могут или выложат ваш код на гитхаб и скажут что это теперь их хобби-проект ;)

[sim0nsays.livejournal.com]

Вопрос номер один - кто такой наладчик???

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

Можно еще задачи в стиле книжки "Как сдвинуть гору Фудзи", про сверх-логичных пиратов, например.

[spamsink]

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

[sim0nsays.livejournal.com]

Тогда простейший кусок кода на С написать или поправить. Дать код с багом, пусть поправит с компилятором.

[spamsink]

У нас по старинке, на грифельной доске, т.к. поток аппликантов невелик. Но да, придется достать из рукава вопрос, который я уже давно не задавал. Банальщина, конечно, насчет двойного побочного эффекта в одном выражении без sequence points, но в своё время позволяло отличать агнцев от козлищ.

[ak_47]

Типа таких: i=i++ + ++i; ? :)

[spamsink]

Это слишком просто. Типа
if (((getchar() << 8) | getchar()) == MAGIC) ....

[ak_47]

Тоже неплохо. :)

П.С. Я подумал над примером. Рискую прослыть козлищем, но не совсем уверен что понимаю о чём речь. В чём двойной побочный эффект? То что вызовы getchar будут в непредсказуемом порядке это ясно. А где ещё проблема? То что сдвиг может не дать 0, если char больше 8 битов или ещё что?

P.P.S. Вспомнил что getchar вообще возвращает int. Так что нуля там не будет.

[spamsink]

Двойной побочный эффект в том, что каждый из двух вызовов getchar() имеет побочный эффект: продвижение текущего положения в файле.
Краевые случаи - не проблема: если в файле меньше двух символов, то как минимум один getchar() вернет EOF (== -1), и выражение будет содержать единицы старше 16 бит, т.е. гарантированно не совпадет с не более чем 16-битной константой, призванной проверять сигнатуру файла.

[ak_47]

Спасибо. Теперь понятно.

[spamsink]

По-видимому, действительно, проще будет просить писать на псевдокоде, если с активным владением Си будут проблемы. Убирание чего-нибудь в строке - хороший тест, да.

[b0p0h0k.livejournal.com]

Построить диаграмму состояний garage door opener.

[spamsink]

Это красиво.

[b0p0h0k.livejournal.com]

И про лампочку не забыть. В нём обычно ещё лпч есть ватт на 30, которая может загораться, гаснуть и мигать.

[spamsink]

С таким уровнем детализации это уже для хардверного инженера задачка, и на нее львиная доля отведенного времени уйдет.

[ak_47]

Я думаю программистское мышление подразумевает следующие вещи:

1. Желание отделять данные от логики. Пример: есть некий скрипт do_A, которыей делает нечто с A. Надо теперь делать B, причём B очень похоже на A, либо вообще идентично. Нормальный человек просто скопирует do_A в do_B, потом откроет новый файл и заменит там везде A на B. (И будет жить счастливо ещё 10 лет.) Программист такого не потерпит и полезет в скрипт разбираться. Сделает из него do_wtvr и будет передавать параметром A или B. Такое выделение данных из логики обыденная вещь у программистов, но почти всегда удивляет остальных. Как следствие, программисты очень не любят всякое hardcoded, а обычные люди относятся к этому спокойно. Можно дать некий псевдокод, где много всего hardcoded и есть повторения. Спросить как можно было бы это улучшить. Или более абстрактно об этом поговорить.

2. Делегирование и indirection. Скажем, обычных людей не смущают вещи вида "#!/usr/local/bin/python27" . Программист напишет "#!/usr/bin/env python". Вообще, желание всё прошить хуками и колбеками - очень программисткая черта. "А вдруг понадобиться что-нибудь вставить, а я не готов?" - так рассуждают программисты. Другая грань этого свойства - вызывание уже готовых тулзов, функций и пр., а не написание их самому. Скажем, не писать скрипт для поиска слова в файлах определённого вида, а запустить grep посреди других операций в пайпе. Из этого как следствие желание модулярности и независимости узлов, а не монолитного решения. Можно человека спросить как бы он решил некую задачу, которая легко разбивается на подзадачи, при этом предупредить что задача скорее всего будет видоизменяться, поэтому хотелось бы иметь robust решение. Программист сразу начнёт клепать модули и интерфейсы. Обычных людей такие вопросы часто ставят в тупик, т.к. они не привыкли разбивать большие задачи на мелкие под-задачи.

3. Программисты мыслят стеком. То что взяли надо положить обратно. То что трогали, надо почистить и вернуть как было. Unwind and rollback всегда подразумеваются. Обычных людей это часто раздражает и они не всегда понимают зачем это надо и тем более зачем это надо делать в обратной последовательности, а не в произвольной.

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

Наверное можно ещё многое придумать, но это то что первым в голову пришло.

[spamsink]

Не всякий программист тут же нахрапом стремится to overdesign. Как известно, среди добродетелей программиста - лень и нетерпение.

[b0p0h0k.livejournal.com]

Стремиться-то надо, но надо ещё иметь judgement свое стремление обуздывать.
А нетерпением пусть ПиЭмы занимаются. Им за это плотют.

[spamsink]

Лозунг настоящего программиста - "Вы этого хотели, вот вам".

[ak_47]

Ну дык опытный программист как раз понимает что код - зло. И старается решать задачи подручными средствами.