Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, Jesmus, Вы писали:
S>Чтобы понять как будет писаться код на реальном проекте нужно давать соответствующие тестовые задачи, чтобы код, хотя бы теоретически, мог использоваться другими.
ну это уже как данность жизни — если требуют выслать пример кода иди решить небольшую тестовую задачу — значит будут смотреть на оформление. То что не было оговорено — плохо конечно, но догадаться можно было, ИМХО. А может это еще и входило в проверку
S>Здесь же требовалось написать _программу_ с четко заданными входными и выходными данными за ограниченное время.
Ну задача вроде не большая, за час можно и реализовать. Оформление — ну минут 15 еще бы заняло.
S>Надо было пытаться угодить корпоративным стандартам кодирования не зная их?
Нет конечно. Смотрится то, что человек вообще придерживается стандартов, а не забивает на них. Просто если есть привычка их использования, то они будут автоматом применяться в новом коде — иначе это будет "написал как смог, затем переписал всё начисто если успел, и не забыл, и не забил".
По крайней мере такой минимум как заголовок функции с описанием входных/выходных параметров должен присутствовать всегда независмо от объема проекта. Пометка ключевых частей алгоритма — крайне желательна.
Давай бегло посмотрим что у тебя в коде, ок? По заданию происходит ввод количества тестовых наборов и несколько групп (x,y). Основной алгоритм выполняется в функции с сигнатурой:
void steps(int i)
Как догадаться что эта функция получает на вход не просмотрев полностью либо код функции, либо код вызова? Что это за i? Количество тестовых наборов? Нет, оказывается это величина интервала (которого в оригинальном задании вообще не было). Почему не назвать переменную более осмыслено — intervalSize, к примеру? Почему бы не написать комментарий что эта функция "определяет количество шагов для прохождения интервала"?
Плохо оттестирована: где в задании сказано что x<y? Вводим интервал в обратном порядке — получаем корень из отрицательного числа. Проверки входных данных в функции нет вообще.
И наконец даже в такой небольшой программе есть ошибки проектирования. Если эта функция не занимается вводом — то почему она занимается выводом? Почему бы ей просто не вернуть значение, а взаимодействие с пользователем пусть будет головной болью другой части программы? Допустим тебе изменили условие задачи — если в коммандной строке указаны файлв, то надо вводить данные из файла, а выводить в другой файл. Сейчас тебе придется переписывать функцию, которая вообще по логике должна быть библиотечной и ей это должно быть до фени. Плюс будешь переписывать все точки вызова, потому что сигнатура функции поменяется.
А всё что надо было — вернуть значение в выходном параметре.
S>Ну да ладно — нет худа без добра, стал немного умнее: до первого собеседования тестовое задание стоит выполнять только от google.
Ну сам я крайне негативно настроен к тестовым заданием, но данное конкретное показалось мне довольно таки адекватным: небольшое, времени займет мало, специфичиское знание тонкостей никому не нужного API не проверяет, оценить как человек привык писать позволяет. И данный конкретный код показывает что человека надо будет учить и код за ним постоянно проверять.
P.S. Не сочти всё это за наезд — но ты сам спросил что могло не понравиться в данном коде. Значит к критике должен был готов Сам я понимаю что ситуации разные бывают — реально не хватило времени, заинтересовался задачей или банально голова болела.
, т.к. мне задача понравилась: чисто алгоритмическая и не было её решения в гугле. На решение 24 часа. S>Но работодателю чем-то не понравилось мое решение. Общался через кадровое агенство и никаких комментариев от работодателя им добиться не удалось, поэтому моя совесть не грызет меня за раскрытие тестового задания. S>Может кто подскажет, что совсем отталкивает?
содержимое функции, цикл while не более 31 (?30?) раз
int len = y-x;
if (len == 0) return 0;
if (len == 1) return 1;
int stepsize = 1, steps = 0;
while(len >= 2*stepsize)
{
len -= 2*stepsize;
stepsize++;
steps += 2;
}
if (len > stepsize) return steps+2;
if (len > 0) return steps+1;
return steps;
, т.к. мне задача понравилась: чисто алгоритмическая и не было её решения в гугле. На решение 24 часа. S>Но работодателю чем-то не понравилось мое решение. Общался через кадровое агенство и никаких комментариев от работодателя им добиться не удалось, поэтому моя совесть не грызет меня за раскрытие тестового задания. S>Может кто подскажет, что совсем отталкивает?
Если я правильно понял задачу, в чем я сомневаюсь, то задача абсолютно идиотическая.
Первый шаг 1, последний 1, промежуточные — без ограничений. Получается что минимальное количество шагов три
шаг 1 = 1
шаг 2 = y-x-2
шаг 3 = 1
Муть полнейшая. Я, кстати, совсем не понял необходимость в векторе, когда задача решается за один проход.
Здравствуйте, Skorodum, Вы писали:
S>Критика по делу, не понравилось отношение: если человек потратил хоть какое-то время и ответил не в духе "задание не корректное, делать не буду", то из элементарной вежливости на ответить.
Ну да, это хамство со стороны работадателя, по любому.
По поводу остальных ответов — я их понимаю, и местами даже соглашаюсь. Лично для меня данное тестовое задание служило бы в качестве затравки для дальнейшей беседы, если бы я решал кого пропустить, а кого нет. Но вопрос был — "что могло не понравиться в коде", на него я и отвечал исходя из практики тестовых заданий нашей фирмы. И я понимаю что после такого кода в нашей конторе тоже бы не допустили бы к интервью. Ответили бы или нет — вот честно говоря не знаю, этим HR занимается, но не допустили бы точно. К солжалению, это данность которую надо иметь в виду.
Предлагаю такое решение.
Для начала определим пороговые случаи абсолютно симметричных прогрессий, составляющих некоторые четные числа (до середины вверх и с средины вниз). Особенность такого представления состоит в том, что бОльшая разница между x и y уже потребует бОльшего количества значений. Вот примеры:
(y-x) мин кол-во элементов
2 2
6 4
12 6
20 8
30 10
42 12
Из этого набора видно, что количество элементов одной из прогрессий (т.е. половины элементов) можно определить как:
n = Floor(sqrt(y-x))
осталось только вернуть искомое количество
if ((y-x) == (n*n)) -- нижний порог
return n * 2 — 1;
else if ((y-x) <= (n*n + n) ) -- верхний порог
return n * 2;
else
return n * 2 + 1;
Здравствуйте, Skorodum, Вы писали:
S>Может кто подскажет, что совсем отталкивает?
Ну вообще поскольку задача относительно простая, то явно собирались смотреть на стиль кода — комментарии, именование переменных, обработка ошибок. Я не смотрел правильность математики (да, вечер, лень), но оформление явно никуда не годится. Или к работодателю ушел другой вариант, с нормальными комментами и именами переменных? Просто по хорошему по комментариям должно понятно назначение и работа программы. Сейчас глядя на код вообще непонятно что и как программа делает — чего-то где-то ввела (без вывода приглашения, без подсказок), чего-то поколбасила, чего-то вывела. В таком коде даже на саму математику смотреть не хочется.
Отсюда, чтобы получить минимальное количество шагов, прогрессия слева должна постоянно расти. Регрессия справа должна постоянно убывать начиная с определённой позиции.
Получается уравнение общего вида:
P + R = X
где:
P — сумма чисел прогрессии до некоторой позиции N.
R — сумма чисел регрессии от некоторой позиции N.
Очевидно, что R зависит от P, иначе можно "не успеть" зарегресситься до +1 по условию задачи. Но также очевидно, что прогрессия и регрессия симметричны для чётных X, т.к. разность соседних шагов тоже симметрична. А т.к. по условиям задачи ближайшие шаги могут совпадать по значению, то для нечётного X можно вставить недостающий шаг в нужное место один раз.
Отсюда X надо привести к чётному в меньшую сторону и поделить на 2, чтобы получить сумму и прогресси (и регресии, т.к. в этом случае P = R).
А дальше надо по сумме прогрессии от +1 до +N (где N — чётное) получить N (надеюсь сами догадаетесь как ).
Если X чётное, то шагов 2xN;
Если X нечётное, то шагов 2xN+1;
Вообщем, как-то так.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Jesmus, Вы писали:
J>ну это уже как данность жизни — если требуют выслать пример кода иди решить небольшую тестовую задачу — значит будут смотреть на оформление. То что не было оговорено — плохо конечно, но догадаться можно было, ИМХО. А может это еще и входило в проверку
Здесь полностью согласен — нужно писать, что именно хочет увидеть работодатель. Потому как ситуации бывают сильно разные. Может быть, задание служит для проверки алгоритмического мышления кандитата и там оценивалось бы совсем другое. В качестве задачки можно было бы что-нибудь более нейтральное дать, с известным алгоритмом. Тогда неоднозначностей в трактовке задания было бы меньше.
S>>Здесь же требовалось написать _программу_ с четко заданными входными и выходными данными за ограниченное время.
J>Ну задача вроде не большая, за час можно и реализовать. Оформление — ну минут 15 еще бы заняло.
Вообще, это характерная олимпиадная задача. В норме командами сдается минут через 15-20 после начала соревнования, максимум — полчаса. Оформление же занимает столько же, если не больше. Как минимум нужно сделать проверку входных данных (не забыть про конец файла и нечисловые данные во вводе), проверку правильности входных чисел в функции (положительны, в правильном порядке), написать контракт функции (переписав условие задачи) и описав правильность алгоритма решения (алгоритм в том виде не тривиален и в production комментарий нужен). Еще можно юнит-тесты написать. Порцию на алгоритм и порцию на ввод/вывод . Так что на час там как раз оформления.
J>Просто если есть привычка их использования, то они будут автоматом применяться в новом коде — иначе это будет "написал как смог, затем переписал всё начисто если успел, и не забыл, и не забил".
А здесь возможны варианты. Стиль и привычка могут зависеть от решаемых задач даже у одного программиста. Например, утилита для частичного разбора лога при поиске какого-то бага скорее всего будет оформлена менее аккуратно, чем production-код. В ней можно и на архитектуру забить, да и на комментарии по большей части. Это все если быть уверенным, что утилита пишется на один раз. Переключение между стилями делается легко.
С указанной задачей еще веселее. Я с олимпиадным опытом на автомате вообще перешел бы на "олимпиадный" стиль, особенно учитывая приведенные выше оценки времени. Логика написания примерно следующая:
После прочтения картины представляем картинку.
Понимаем, что подходит "жадный" алгоритм — выбираем максимальный шаг, идем до него затем уменьшая шаги. Если хватило — можно что-то уменьшить. Если не хватило — нужно еще шаг и увеличить максимальный.
Понимаем, что максимум — примерно корень из N.
Разбираться с корректностью округлений и границ нет времени (проверка корректности формул требует большой аккуратности по сравнению с логикой проверки от количества шагов), берем корень из N — 3, например, ограничиваем снизу 0, умножаем на 2, получаем количество шагов.
Так как взяли заведомо меньше, поувеличиваем на один, пока максимальное расстояние не достигнет (или превысит) входного значения.
Замечаем, что 2^31 — это много, а мы будем умножать. Объявляем все переменные как long, чтобы не разбираться с переполнением.
Ну и наконец считаем количество шагов. Так как искать одну правильную формулу лень (тоже сложно доказывать корректность), рисуем две картинки для четного и нечетного количества шагов, по которым пишем две формулы.
Как побочный эффект условия задачи появляются переменные x и y. Параметры — что-нибудь вроде n, k. В результате — код на первый взгляд выглядит не очень аккуратно и логично (что-то можно было свести в одну формулу, уменьшить количество проверок, сразу посчитать точное решение), но зато написан быстро и работает.
Кстати, еще замечу, что вывод решения в олимпиадных задачах достаточно часто попадает в "решатель". Это если входных данных немного (и ими занимается main программы), а для вычисления создаются какие-нибудь структуры, которые нужно выводить. Ну например, временные массивы и т.п. Или эти же массивы заводятся глобальными (с запасом +2 или +3 от условий задачи, на всякий случай), что на красоте программы тоже сказывается не лучшим образом.
Здравствуйте, Jesmus, Вы писали:
J>ну это уже как данность жизни — если требуют выслать пример кода иди решить небольшую тестовую задачу — значит будут смотреть на оформление. То что не было оговорено — плохо конечно, но догадаться можно было, ИМХО. А может это еще и входило в проверку
Тут была пара ответов, показавших непонимание сути задачи, а Вы про говорите про совсем уж высокие материи.
S>>Здесь же требовалось написать _программу_ с четко заданными входными и выходными данными за ограниченное время.
J>Ну задача вроде не большая, за час можно и реализовать. Оформление — ну минут 15 еще бы заняло.
Так и вышло. И этого не достаточно чтобы продолжить разговор или хотя бы ответить? Вам вот ведь не лень в рабочее время отвечать незнакомому человеку, а я для них теоретически уже чуть больше, чем человек с улицы. Получается, что хоть чем-то непонравившийся соискатель принципиально не достоин ответа...
S>>Надо было пытаться угодить корпоративным стандартам кодирования не зная их?
J>Нет конечно. Смотрится то, что человек вообще придерживается стандартов, а не забивает на них. Просто если есть привычка их использования, то они будут автоматом применяться в новом коде — иначе это будет "написал как смог, затем переписал всё начисто если успел, и не забыл, и не забил".
У меня почему-то было желание сделать как можно более легкий код... Наверное, был не прав.
J>По крайней мере такой минимум как заголовок функции с описанием входных/выходных параметров должен присутствовать всегда независмо от объема проекта. Пометка ключевых частей алгоритма — крайне желательна.
Без описания задачи — комментарии к этому решению все равно смысла не имеют, а с задачей — тем более. Привычка писать комментарии, бесспорно, правильная, но даже если ее нет, то вырабатывается она за один день — достаточно посмотреть код существующих проектов на новом месте.
J>Давай бегло посмотрим что у тебя в коде, ок? По заданию происходит ввод количества тестовых наборов и несколько групп (x,y). Основной алгоритм выполняется в функции с сигнатурой:
J>
J>void steps(int i)
J>
J>Как догадаться что эта функция получает на вход не просмотрев полностью либо код функции, либо код вызова? Что это за i? Количество тестовых наборов? Нет, оказывается это величина интервала (которого в оригинальном задании вообще не было). Почему не назвать переменную более осмыслено — intervalSize, к примеру? Почему бы не написать комментарий что эта функция "определяет количество шагов для прохождения интервала"?
J>Плохо оттестирована: где в задании сказано что x<y? Вводим интервал в обратном порядке — получаем корень из отрицательного числа. Проверки входных данных в функции нет вообще.
Сори, в условии было сказано, что x < y, копирование из pdf кривое. В коде явно оговорено что нет проверки входных значений. Если проверять ввод с клавиатуры на верность заданным условиям код будет в 10 раз больше, и это будет уже совсем другое задание.
J>И наконец даже в такой небольшой программе есть ошибки проектирования. Если эта функция не занимается вводом — то почему она занимается выводом? Почему бы ей просто не вернуть значение, а взаимодействие с пользователем пусть будет головной болью другой части программы? Допустим тебе изменили условие задачи — если в коммандной строке указаны файлв, то надо вводить данные из файла, а выводить в другой файл. Сейчас тебе придется переписывать функцию, которая вообще по логике должна быть библиотечной и ей это должно быть до фени. Плюс будешь переписывать все точки вызова, потому что сигнатура функции поменяется. J>А всё что надо было — вернуть значение в выходном параметре.
Для меня ключевым условием было что надо было написать _программу_, и хотелось сделать ее как можно короче. Если бы требовалось написать функцию, тогда — бесспорно.
J>Ну сам я крайне негативно настроен к тестовым заданием, но данное конкретное показалось мне довольно таки адекватным: небольшое, времени
займет мало, специфичиское знание тонкостей никому не нужного API не проверяет, оценить как человек привык писать позволяет.
Мне тоже задание понравилось. Ожидал лучшего отношения от компании.
J>И данный конкретный код показывает что человека надо будет учить и код за ним постоянно проверять.
Мало кто приходит и начинает новый проект с девственно-чистого листа. Есть корпоративные стандарты и существующий код. Если человек хоть немного способен к обучению и есть желание, то сам поймет или будет необходим минимум замечаний, а такие задачи как раз показывают насколько уже закостенели мозги.
J>P.S. Не сочти всё это за наезд — но ты сам спросил что могло не понравиться в данном коде. Значит к критике должен был готов Сам я понимаю что ситуации разные бывают — реально не хватило времени, заинтересовался задачей или банально голова болела.
Критика по делу, не понравилось отношение: если человек потратил хоть какое-то время и ответил не в духе "задание не корректное, делать не буду", то из элементарной вежливости на ответить.
, т.к. мне задача понравилась: чисто алгоритмическая и не было её решения в гугле. На решение 24 часа.
Но работодателю чем-то не понравилось мое решение. Общался через кадровое агенство и никаких комментариев от работодателя им добиться не удалось, поэтому моя совесть не грызет меня за раскрытие тестового задания.
Может кто подскажет, что совсем отталкивает?
Здравствуйте, Skorodum, Вы писали:
S>Может кто подскажет, что совсем отталкивает?
дрочуны они в том представительстве. Вы уверены что хотите у них работать? =)
Ну незачем давать такие задания апп девелоперу. В реальной жизни такое никогда ему не встретится.
Здравствуйте, Alf, Вы писали:
Alf>Здравствуйте, Skorodum, Вы писали:
Alf>дрочуны они в том представительстве. Вы уверены что хотите у них работать? =) Alf>Ну незачем давать такие задания апп девелоперу. В реальной жизни такое никогда ему не встретится.
Я уже устроился. Мне задание понравилось: мозги немного напрягает и никакой практической полезности, интересно что неправильно.
Внутри компанию не видел и не с кем не общался, так что не знаю, насколько я захотел бы там работать.
, т.к. мне задача понравилась: чисто алгоритмическая и не было её решения в гугле. На решение 24 часа. S>Но работодателю чем-то не понравилось мое решение. Общался через кадровое агенство и никаких комментариев от работодателя им добиться не удалось, поэтому моя совесть не грызет меня за раскрытие тестового задания. S>Может кто подскажет, что совсем отталкивает?
, т.к. мне задача понравилась: чисто алгоритмическая и не было её решения в гугле. На решение 24 часа. S>Но работодателю чем-то не понравилось мое решение. Общался через кадровое агенство и никаких комментариев от работодателя им добиться не удалось, поэтому моя совесть не грызет меня за раскрытие тестового задания. S>Может кто подскажет, что совсем отталкивает?
Я не силен срр, но при y — x = 1 оно нормально себя поведет?
Здравствуйте, ilnar, Вы писали:
I>Здравствуйте, Skorodum, Вы писали:
S>>Тестовое задание от питерского представительства крупной западной конторы. S>>Разместил в этюдах
, т.к. мне задача понравилась: чисто алгоритмическая и не было её решения в гугле. На решение 24 часа. S>>Но работодателю чем-то не понравилось мое решение. Общался через кадровое агенство и никаких комментариев от работодателя им добиться не удалось, поэтому моя совесть не грызет меня за раскрытие тестового задания. S>>Может кто подскажет, что совсем отталкивает?
I>содержимое функции, цикл while не более 31 (?30?) раз I>
Здравствуйте, Handie, Вы писали:
H>Здравствуйте, Skorodum, Вы писали:
H>Муть полнейшая. Я, кстати, совсем не понял необходимость в векторе, когда задача решается за один проход.
Ну вот если бы я так ответил, было бы не удивительно что мне не предложили даже собеседования.
Здравствуйте, Jesmus, Вы писали:
J>Здравствуйте, Skorodum, Вы писали:
S>>Может кто подскажет, что совсем отталкивает?
J>Ну вообще поскольку задача относительно простая, то явно собирались смотреть на стиль кода — комментарии, именование переменных, обработка ошибок. Я не смотрел правильность математики (да, вечер, лень), но оформление явно никуда не годится. Или к работодателю ушел другой вариант, с нормальными комментами и именами переменных? Просто по хорошему по комментариям должно понятно назначение и работа программы. Сейчас глядя на код вообще непонятно что и как программа делает — чего-то где-то ввела (без вывода приглашения, без подсказок), чего-то поколбасила, чего-то вывела. В таком коде даже на саму математику смотреть не хочется.
Какие комментарии к полуолимпиадным задачам? Наверняка они уже видели не одно решение и комментарии по способу решения им ничего нового не скажут. Задание чисто математическое, на 7 строчек. Если бы это было что-то типа "чат в локальной сети", "копирование двусвязного списка с одним рандомным указателем", "умный указатель на массив", тогда да: комментарии, обработка ошибок и т.д. и т.п.
Ну вот я примерно так же и рассуждал, только как-то чуть попроще
Так откуда такой снобизм что не отвечают почему выполнение не понравилось? Сложно 2 слова сказать/написать девушки из кадрового агенства?
Находящиеся за границей компании ведут себя куда вежливее.
Вот так и складывается репутация компании.
З.Ы. Про плохие слухи о Parallels знают даже в кадровом агентстве, хоть лично я против них пока ничего не имею.
Здравствуйте, ilnar, Вы писали:
I>Здравствуйте, Skorodum, Вы писали:
S>>Тестовое задание от питерского представительства крупной западной конторы. S>>Разместил в этюдах
, т.к. мне задача понравилась: чисто алгоритмическая и не было её решения в гугле. На решение 24 часа. S>>Но работодателю чем-то не понравилось мое решение. Общался через кадровое агенство и никаких комментариев от работодателя им добиться не удалось, поэтому моя совесть не грызет меня за раскрытие тестового задания. S>>Может кто подскажет, что совсем отталкивает?
I>содержимое функции, цикл while не более 31 (?30?) раз I>
исправил
if (len > stepsize+1) return steps+2;
т.к. можно еще на один пойти выше, и пойти на спуск
иначе если выше, придется где-то в 2-х местах шагнуть не меняя размер шага
если меньше, то только один
Здравствуйте, ilnar, Вы писали:
I>Здравствуйте, ilnar, Вы писали:
I>>Здравствуйте, Skorodum, Вы писали:
S>>>Тестовое задание от питерского представительства крупной западной конторы. S>>>Разместил в этюдах
, т.к. мне задача понравилась: чисто алгоритмическая и не было её решения в гугле. На решение 24 часа. S>>>Но работодателю чем-то не понравилось мое решение. Общался через кадровое агенство и никаких комментариев от работодателя им добиться не удалось, поэтому моя совесть не грызет меня за раскрытие тестового задания. S>>>Может кто подскажет, что совсем отталкивает?
I>>содержимое функции, цикл while не более 31 (?30?) раз I>>
I>исправил I>if (len > stepsize+1) return steps+2; I>т.к. можно еще на один пойти выше, и пойти на спуск I>иначе если выше, придется где-то в 2-х местах шагнуть не меняя размер шага I>если меньше, то только один
ступил под вечер, stepsize после while и так больше на 1 сделанного шага, +1 не нужен
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, Jesmus, Вы писали:
J>>Здравствуйте, Skorodum, Вы писали:
S>>>Может кто подскажет, что совсем отталкивает?
S>Какие комментарии к полуолимпиадным задачам? Наверняка они уже видели не одно решение и комментарии по способу решения им ничего нового не скажут. Задание чисто математическое, на 7 строчек. Если бы это было что-то типа "чат в локальной сети", "копирование двусвязного списка с одним рандомным указателем", "умный указатель на массив", тогда да: комментарии, обработка ошибок и т.д. и т.п.
Ты немного не понял — комментарии нужны им не для того, чтобы понять как задача решена, а для того чтобы понять как ты писать будешь код на реальном проекте. Если бы их интересовала сама задача, то она была бы задана на очной беседе — "вот вам ручка, бумага — накидайте алгоритм за час. Можно на псевдоязыке". Если подобная задача дана на дом — то задачу надо оформить так, чтобы даже человек впервые видящий ее смог разобраться что происходит. Ну или чтобы эту функцию можно было бы без изменений перенести в библиотеку. Это я говорю как человек периодически проверяющий тестовые задания. Просто если кандидат пишет не совсем тривиальный алгоритм (с точки зрения понять что он делает не видя исходную задачу) без единой строчки комментария, то такой кандидат скорее всего не будет пропущен к интервью. Правда мы этот момент специально оговариваем когда даем тестовое задание, что оформление кода равно по важности корректности решения.
Не сочти это за наезд или переход на личности — но похоже ты недавно закончил обучение или работал до этого в полугосударственной конторе, верно?
Здравствуйте, Jesmus, Вы писали:
J>Ты немного не понял — комментарии нужны им не для того, чтобы понять как задача решена, а для того чтобы понять как ты писать будешь код на
Чтобы понять как будет писаться код на реальном проекте нужно давать соответствующие тестовые задачи, чтобы код, хотя бы теоретически, мог использоваться другими. Например, как в многолетних заданиях в SpbSoftware где еще и явно оговорено — нужны комментарии. Хоть задания уже и много раз решены, они не меняются, значит главное стиль, оформление. Здесь же требовалось написать _программу_ с четко заданными входными и выходными данными за ограниченное время.
Надо было пытаться угодить корпоративным стандартам кодирования не зная их?
З.Ы. Телепатов развелось... Может просто спросить кандидата использовался ли раньше какой-нибудь стандарт кодирования, какие требования к комментариям были, почему лучше ограничивать длину строки кода, в какой кодировке лучше хранить исходники, что такое Doxygen и т.д.?
Ну да ладно — нет худа без добра, стал немного умнее: до первого собеседования тестовое задание стоит выполнять только от google.
Здравствуйте, Jesmus, Вы писали:
J>По поводу остальных ответов — я их понимаю, и местами даже соглашаюсь. Лично для меня данное тестовое задание служило бы в качестве затравки для дальнейшей беседы, если бы я решал кого пропустить, а кого нет. Но вопрос был — "что могло не понравиться в коде", на него я и отвечал исходя из практики тестовых заданий нашей фирмы. И я понимаю что после такого кода в нашей конторе тоже бы не допустили бы к интервью. Ответили бы или нет — вот честно говоря не знаю, этим HR занимается, но не допустили бы точно. К солжалению, это данность которую надо иметь в виду.
Понял, спасибо. Когда буду в следующий раз менять работу не забуду.
).
ступил под вечер, stepsize после while и так больше на 1 сделанного шага, +1 не нужен
