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

G>Потому что это задача не практическая, как и программирование сортировки. Все уже давно в либах есть и на практике никогда (в смысле вообще никогда) не приходится её писать.
G>А если человек не делает что-то постоянно, то просто теряется навык.

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

G>Бред. Отсеивать человека по одной задаче — крайне неудачная идея, как и спрашивать про крышки люков, гору фудзи или количество шариков в автобусе.

А как тогда отсеять людей, не способных программировать? Давать на дом тестовые задания? Я так понял, в среде программистов отношение к ним очень негативное. Задавать технические вопросы? Вот на них ответы человек действительно может не знать, если раньше не работал. Кроме того, мне ведь программист нужен, а не зубрилка. Сейчас интернет есть, если человек с мозгами любую техническую информацию он за 5 минут найдёт (кстати, у меня есть идея проверять навык поиска тех.инфы в интернете, просто я еще не придумал, как это грамотно реализовать).

G>На собеседовании в первую очередь надо проверить что человек справится с той работой, которой его нагрузят. Для этого можно предложить ему задачу и пусть расскажет ход решения. Или напрмиер тестовое задание (небольшое) заранее дать.

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

G>Ты подумай какой процент этих задач на собеседованиях решается соображалкой, а какой — предварительным гуглением?

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

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

G>>>Это задача дается для проверки понимания как алгоритмы отображаются на конкретные особенности системы типов и рантайма.
L>>Чего?

G>Ну напиши работающий код, который string в C# разворачивает.

1. Давно ли строка стала списком?
2.

var sb = new SringBuilder(s.Length);
for (int i = s.Length-1; i >=0; i--)
{
    sb.Append(s[i]);
}
return sb.ToString();

или перегнать в char[], перевернуть массив и построить новую строку.

Зачем тут рекурсия? Причем тут особенности системы типов и рантайма?

Как набираешь, того и получаешь.

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

Кто вам нужен-то? Так и действуйте.

Здравствуйте, Паблик Морозов, Вы писали:

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

    List reverseList(List originalList) {
        List result = new ArrayList();

        for (int i = result.size(); i > 0; ++i) {
            result.add(originalList.get(i));
        }
        return result;
    }

То есть банальные ошибки из за невнимательности, да и на бумажке вспомнить о том, что нужно size — 1 и тому подобные проверки делать лень. Лично я б не стал по таким ошибкам судить о квалификации, более того, такие задачи вообще б не стал давать. А если б дал — я б и таким удовлетворился. А заодно б побеседовал о том, что лучше — вот так с созданием нового, или на месте, какие плюсы и какие минусы.
Или на месте его нужно обращать?
Ладно. Такое решение пойдет?

    void reverseList(List originalList) {
        reverseList(originalList, 0, originalList.size() - 1);
    }

    void reverseList(List originalList, int start, int end) {
        if (start >= end) {
            return;
        }
        Object tmp = originalList.get(start);
        originalList.set(start, originalList.get(end));
        originalList.set(end, tmp);
        reverseList(originalList, start + 1, end - 1);
    }

Но уже такое на бумажке писать ломает, хотя это максимальная сложность, к которой я терпимо отношусь в случае бумажки. А если б было:

    void reverseList(List originalList) {
        reverseList(originalList, 0, originalList.size());
    }

Такое б прокатило — или ошибка, no hire?
Или явно итеративное решение без рекурсии требуется, и кто такое написал — типа нельзя брать (ибо в большинстве институтов почему то рекурсивные алгоритмы не любят)? Так явно итеративное решение даже на компе лень набивать, не то что на бумажке.

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

L>Меня однажды спросили про то, как интеграл численно считается. Выяснилось, что процентов 80 соискателей не в состоянии ответить на вопрос из школьной программы.

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

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

KP>Кого ищите то? Те же плюсисты, обычно, решают в лет. У разработчиков более высокоуровневых языков часто вызывает проблемы, сам не знаю почему.

C#/Java. Среди программистов на C#/Java больше идиотов (может и правда плюсистов брать и переучивать)?

Здравствуйте, Паблик Морозов, Вы писали:

L>>Меня однажды спросили про то, как интеграл численно считается. Выяснилось, что процентов 80 соискателей не в состоянии ответить на вопрос из школьной программы.

ПМ>Такое я никогда не спрашиваю. Вообще ничего, что бы требовало знаний (особенно не относящихся к работе). Хотя мне любытно, зачем вам задали этот вопрос.

Работа предполагала знание математики хотя бы в школьном объеме.

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

E>Насколько я понимаю, кандидаты пишут что то вроде этого (специально бажную версию кидаю):
E>

E>    List reverseList(List originalList) {
E>        List result = new ArrayList();

E>        for (int i = result.size(); i > 0; ++i) {
E>            result.add(originalList.get(i));
E>        }
E>        return result;
E>    }
E>

List в Java это массив, а не список. В списке, например, операция получения размера линейно зависит от времени, поэтому её обычно не реализуют.

Здравствуйте, Паблик Морозов, Вы писали:

ПМ>Здравствуйте, gandjustas, Вы писали:

G>>Потому что это задача не практическая, как и программирование сортировки. Все уже давно в либах есть и на практике никогда (в смысле вообще никогда) не приходится её писать.
G>>А если человек не делает что-то постоянно, то просто теряется навык.

ПМ>Мне не надо, чтобы человек помнил как это делать (я специально варьирую задания), мне надо, чтобы человек был в состоянии написать цикл с тремя переменными. Если он не сможет сделать такую простую задачу, как он сможет проектировать сложные системы? Там в голове надо держать гораздо больше, чем 3 переменные.

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

G>>Бред. Отсеивать человека по одной задаче — крайне неудачная идея, как и спрашивать про крышки люков, гору фудзи или количество шариков в автобусе.

ПМ>А как тогда отсеять людей, не способных программировать? Давать на дом тестовые задания? Я так понял, в среде программистов отношение к ним очень негативное.
Я уже писал свойства хорошего задания. Главное чтобы его можно было сделать не более чем за 4 часа без предварительной подготовки.

ПМ>Задавать технические вопросы? Вот на них ответы человек действительно может не знать, если раньше не работал. Кроме того, мне ведь программист нужен, а не зубрилка. Сейчас интернет есть, если человек с мозгами любую техническую информацию он за 5 минут найдёт (кстати, у меня есть идея проверять навык поиска тех.инфы в интернете, просто я еще не придумал, как это грамотно реализовать).
Сейчас и решение задачи о развороте списка найти можно, и вообще большая часть кода, который пишут разработчики уже есть в интернете


G>>На собеседовании в первую очередь надо проверить что человек справится с той работой, которой его нагрузят. Для этого можно предложить ему задачу и пусть расскажет ход решения. Или напрмиер тестовое задание (небольшое) заранее дать.

ПМ>Реальные задачи у нас большие и требуют погружения в предметную область.
А ты опиши задачу так чтобы предметная область не требовалась. Что бы вы не делали — все сводится к набору структур данных, алгоритмов и используемых библиотек.

ПМ>Поэтому и даю синтеческую, которая на порядок проще и решается за 5 минут.
Это ты думаешь что проще, а на деле не проще. Потому что требует знаний, которые люди не используют каждый день.


G>>Ты подумай какой процент этих задач на собеседованиях решается соображалкой, а какой — предварительным гуглением?
ПМ>Ну да, читеры проходят, по отношению к читерам принимаются дополнительные меры. Но если система эффективна не на 100%б а хотя бы на 50% она уже наполовину разгружает специалистов.
Она также на 50% "эффективна" в другую сторону, то есть отсеивает тех, кого не должна.
Я бы не стал такой пользоваться.

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

E>    List reverseList(List originalList) {
E>        List result = new ArrayList();

E>        for (int i = result.size(); i > 0; ++i) {
E>            result.add(originalList.get(i));
E>        }
E>        return result;
E>    }
E>

E>То есть банальные ошибки из за невнимательности, да и на бумажке вспомнить о том, что нужно size — 1 и тому подобные проверки делать лень. Лично я б не стал по таким ошибкам судить о квалификации, более того, такие задачи вообще б не стал давать. А если б дал — я б и таким удовлетворился. А заодно б побеседовал о том, что лучше — вот так с созданием нового, или на месте, какие плюсы и какие минусы.

Правильно, так как сами такие ошибки допускаете: "++i"

Здравствуйте, Паблик Морозов, Вы писали:

ПМ>Может быть я что-то не понимаю в этой жизни? Не могли бы более опытные товарищи поделиться опытом и ответить на следующие вопросы:
ПМ>1. Если человек не в состоянии обратить список, способен ли он вообще написать что-нибудь разумное или сразу нафиг?
ПМ>2. Если сраз нафиг, то как грамотно построить интервью, чтобы дать эту задачу в самом начале, не слишком сильно человека шокировав, и распрощаться втечение пяти минут, не слишком обидев?

А почему у вас в организации принимают решения "годен" или "негоден" на основе попадания в шаблонное решение для одной задачи? Не следует ли такого интервьюера уволить?

Может хватит превращать этот форум в троллоферму? Тут почти каждый месяц создаются топики "почему кандидаты не могут решить простую задачу?" и "почему интервьюеры задают задачи, дико оторванные от реальной жизни?". ИМХО и то и другое — отсутствие опыта проведения/прохождения собеседований и жизненного опыта вообще.

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

E>>То есть банальные ошибки из за невнимательности, да и на бумажке вспомнить о том, что нужно size — 1 и тому подобные проверки делать лень. Лично я б не стал по таким ошибкам судить о квалификации, более того, такие задачи вообще б не стал давать. А если б дал — я б и таким удовлетворился. А заодно б побеседовал о том, что лучше — вот так с созданием нового, или на месте, какие плюсы и какие минусы.

A>Правильно, так как сами такие ошибки допускаете: "++i"

Почемы вы считаете это ошибкой?

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

>> Почему 9 из 10 соискателей не могут её решить?
V>Сколько платишь за решение этой задачи?

V>А за бесплатно, сам свое время гробь.

Да, че там. За каждый ответ на собесодовании надо платить! По типу «Кто хочет стать миллионером?»

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

ПМ>>Почему 9 из 10 соискателей не могут её решить? Причём у людей минимум от 3-х лет опыта разработки, позиционируют они себя, как сеньёр-девелоперы, ЗП вроде конкурентноспособная (немного выше, если отсортировать вакансии с HH по зарплате и пропустить жöлтенькие).

G>Потому что это задача не практическая, как и программирование сортировки. Все уже давно в либах есть и на практике никогда (в смысле вообще никогда) не приходится её писать.

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

Но ты прав относительно потери навыка, большинство программистов попросту занимается другими задачами — в основном слепить запрос к БД и вывести цифирь на форме. Т.е. сложить из кубиков могут, а выпилить что-то свое — увы.

G>На собеседовании в первую очередь надо проверить что человек справится с той работой, которой его нагрузят. Для этого можно предложить ему задачу и пусть расскажет ход решения. Или напрмиер тестовое задание (небольшое) заранее дать.

Это может ввести в еще бОльший ступор. Все таки в реальных задачах большое количество исходных данных. А для проверки вменяемости кандидата вполне достаточно простой синтетической. Вроде той, что описывает ТС.

Может помочь дать кандидату домашнее задание на пару-тройку часов. Это чтобы исключить влияние стресса.

Одна известная на кывте компания давала три часа времени, компьютер и просила написать игру "Сапер"
Другая (малоизвестная здесь) предлагала на базе стандартного MFC примера drawcli реализовать snap-to-object во время редактирования. Но сроку давали неделю.

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

A>>Правильно, так как сами такие ошибки допускаете: "++i"

L>Почемы вы считаете это ошибкой?

Я думаю потому, что список в примере обходится с конца .

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

L>>Почемы вы считаете это ошибкой?

A>Я думаю потому, что список в примере обходится с конца .

Упс.

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

A>List в Java это массив, а не список. В списке, например, операция получения размера линейно зависит от времени, поэтому её обычно не реализуют.

В Java List бывает и на основе массива и на основе связанного списка. Впрочем сложность size() в обоих случаях O(1).

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

А>А почему у вас в организации принимают решения "годен" или "негоден" на основе попадания в шаблонное решение для одной задачи? Не следует ли такого интервьюера уволить?

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

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

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

Чтобы деревья балансировать, надо действительно алгоритм знать, сам человек его за пять минут не изобретёт. Быстрая сортировка — примитивнейший алгоритм, если человек его хоть раз в жизни видел, то напишет без проблем. Хотя если не знает, о чем речь, то может и не написать (хотя незнание алгоритма быстрой сортировки — тоже хреновый показатель).

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

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


G>Это ты думаешь что проще, а на деле не проще. Потому что требует знаний, которые люди не используют каждый день.

каких знаний требует задача обращения списка??

G>Она также на 50% "эффективна" в другую сторону, то есть отсеивает тех, кого не должна.

Это кого, например?

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

A>Правильно, так как сами такие ошибки допускаете: "++i"
Собеседующим же можно допускать ошибки — это кандидатам нельзя .

PS Второй вариант я даже проверил, а первый как заведомо неработоспособный я даж не стал проверять