Да, про то, что навык пользования ручкой отмирает за не надобностью +1.

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

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

2. Если человек не может написать запрос руками - только конструктор - лично у меня возникает вопрос: а как этот человек вообще код читает(код того же запроса) ?

3. Инструментальные средства, это конечно хорошо. Но... во времена учёбы, преподаватель по основам алгоритмизации и программирования, постоянно говорила, что программист должен работать без компьютера. Суть в том, что можно обратиться в в справку что бы посмотреть назначение параметров, возвращаемый результат и т.д... но имена функций будь добр, знай.

4. Код на бумаге легко оценить - по ходу его написания. Просто экономит время обоих сторон.

5. Держать отдельно ресурсы(компьютер, базу... ) для собеседования накладно. А пускать за свой компьютер... я бы не пустил(по сути, человека с улицы). Да и проводить собеседование непосредственно за свои рабочем местом(да ещё если не один в кабинете) это, как мне кажется, дурной тон. Идеально - отдельная комната, переговорная...

6. Устное собеседование, проводится не для выявления проф.пригодности, а для того, что бы посмотреть на психологию этого человека.

Last1CmenThe Dim!2. Если человек не может написать запрос руками - только конструктор - лично у меня возникает вопрос: а как этот человек вообще код читает(код того же запроса) ?

ну вот смотри
на английском я читая текст суть уловлю и скорее всего пойму а вот написать подобное врядли
просто практика я "чтец" а не "писец" :)

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

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

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

Зачем на собеседовании писать "большие" запросы?
Я бы сформулировал вопрос так: напишите запрос, который покажет остатки и обороты за период по некоторому условию.
Смотрел бы вот на что:
1. Из какой таблицы человек выбирает .ОстаткиИОбороты или прямо из регистра(скажите, ответ очевиден? а индивиды попадались)
2. Задание условий для отбора "там" или "там".

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

ЕСЛИ ТабличнаяЧасть.Ссылка.Контрагент ....

а то и через три точки.
Кроме того, что с чем джоинить будет, ТЧ с шапкой, или шапку с ТЧ.

Если бы, человек написал правильно, я бы привел не правильный пример и спросил бы в чем разница.

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

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

В конструкторе или "от руки" - да какая разница?


sWinTyzну во первых я просто могу открыть этот запрос в конструкторе и посмотреть что к чему
Конечно, никто не мешает, а что это(сам конструктор) даст?

Язык запросов, прост для изучения - всего то несколько операторов. Проверять их номинального знания смысла(ИМХО) не иммет.
А вот то, как их(конструкции языка запроса) использовать, это совершенно другой разговор.

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

sWinTyzточно
ошибится и в конструкторе легко можно
Не понял, что точно?

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

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