Комментарии 4
Осторожнее с задачками на подумать/математику, это может оказаться задачка из ЕГЭ)
Ночью разбуди, вспомню общее решение. С простыми числами от 1 до N общий смысл со всеми нюансами такой был:
for (k = 2; k <= N; k++) { for (I = 2; I <= sqrt(k): I++) { if (k%i==0) continue (верхний for) } print(k) }
Их лучше не использовать чисто по той утилитарной причине, что простые задачи вам позавчерашний школьник решит по памяти, а сложные не решит тот самый единственный любитель олимпиадного программирования, который знает теорию чисел, а если не запариваться про оптимизации вообще и решать полным перебором, то зачем оно вообще?
Протестировал ваш вариант, сравнил со скоростью решета. На больших n решето на питоне выигрывает. При n равном и больше 100000.
Даже такую простую задачу как вычисление простых чисел от 1 до N можно решить несколькими способами. В голову прямо сейчас приходит сделать этот процесс не ленивым, т.е. посчитать при старте приложения все числа ограниченные типом (int в Java, например) и возвращать уже его. Можно тут же и поговорить о трейдоффах в виде используемой памяти и т.д.
Хорошо, когда хоть кто-то пытается понять, в чём ошибки найма разработчиков. И очень плохо, что таких людей очень мало, что к ним часто не прислушивается начальство и вообще всё сводится к очередной ненужной бюрократии и сильно растянуто по времени.
Чем проще процесс поиска нового сотрудника, тем лучше для всех. Согласен с тем, что этапов должно быть два - 15 минут беседы с кадровиком (уж простите, но не люблю я это слово - "эйчар") и техническое собеседование на 1 час. И очень важно, во-первых, сократить время между этими двумя этапами, и во-вторых, обязательно своевременно давать соискателю обратную связь (что, к сожалению, большая редкость!).
Как тимлиду не нанять себе разработчика