информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяСетевые кракеры и правда о деле ЛевинаВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft закрыла серьёзную уязвимость,... 
 Прощаемся с Windows 7 
 С наступающим 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / humor
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Перечисленное тобой - это признаки очень плохого менеджмента... 21.10.08 15:34  Число просмотров: 2953
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
> Стрессоустойчивоть - одно из требований к соискателям. Как
> же сорванные сроки, постоянно изменяющиеся требования, риск
> увольнения и т.п.? Если по любой из этих причин ты начнешь
Перечисленное тобой - это признаки очень плохого менеджмента в компании. Я бы в такой компании не хотел работать. К тому же стрессоустойчивость человека - вещь безусловно важная, но не единственная. Как ты застрахуешься от того что он не будет, например, банально медленно работать, просиживая рабочее время в Интернете? Стрессоустойчивость - это уже несколько из другой области, и не надо увязывать ее с результатом решения задачи.

> Я такой же. На интервью смотрят за ходом твоих размышлений.
> Если ты молча продумаешь полчаса, то интервьер не будет
> тебя ждать (ибо в период молчания ты ничем не будешь
> отличаться от просто дурака, но узнать чего же ты стоишь
> все таки надо). Он даст тебе твои полчаса на задачу, если
> ты сходу начнешь РАССУЖДАТЬ, если же ты будешь сидеть молча
> - он перейдет к другой задача. Просто чтобы дать ТЕБЕ шанс
> показать себя
Многим людям мешает рассуждение вслух, например. Рассуждать можно, если задали задачу достаточно общего толку, типа: как бы ты стал писать интерпретатор? С целесообразностью послушать такие рассуждения я вполне согласен. Над задачей же которую предлагается именно решить, часто не порассуждаешь. Как в той же задаче со стеклянными шарами.

> Бывают, но не довольно редко. Вот данную конкретную задачу
> лично я решил довольно быстро. После некоторых размышлений
> этот алгоритм оказался идеальным для не очень больших чисел
Ну это все же достаточно простая задача, которая решается последовательно. Здесь не может быть никакой загвоздки, если человек знаком с арифметикой. Задачи такого уровня не показывают интеллект - только лишь отсеивают совсем баранов.

> ОЯЕБУ. А что эту задачу дают на собеседованиях? Это ж паззл
> чистейшей воды, действительно не имеющий отношения к
> программированию. Лично я тупил над ней несколько часов -
> никакого собеседования не хватило бы. Я сходу могу привести
> еще несколько подобных задачек.
Да, реальный случай, в крупной компании. Но там у них вообще много интересного было.

> Парадокс Монти-Холла наверное знаешь. Как раз по теорверу.
Да, знаю. Хотя не понял при чем он здесь. До решения конечно трудно додуматься сразу, но эта задача в своем роде уникальная. Сколько я не искал подобных задачь по терверу - все остальные решаются достаточно просто.

> АВЛ - устаревшее говно. RB-деревья рулят :-)
Может быть. Я не знаток деревьев.

> Хм, я тоже "подзабыл" и сходу не придумал как можно
> транспонировать матрицу умножением. Полез в
> http://en.wikipedia.org/wiki/Transpose и тоже ничего
> подобного не обнаружил. Что то мне подсказывает, что это 1.
> Невозможно 2. Ненужно, ибо транспонирование матрицы гораздо
> более простая операция, чем умножение матриц.
Я вероятно не так немного выразился. Он не матрицу транспонировал, а вычислял новые координаты точек через умножение на матрицу поворота. Это конечно вырожденный клинический случай, но он показателен. Я не раз видел как программисты тратили несколько дней на "оптимизацию" и разработку совершенно не критичных вещей, и в результате рождали такое говно, которое падало через раз. Причем на этапе разработки, когда еше никаких проблем с производительностью не начиналось. Вот поэтому склонность к поиску оптимальных решений меня несколько смущает.
<humor>
Senior PHP developer with 10+ years of using PHP 18.10.08 05:20  
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 18.10.08 05:20  Количество правок: 1
<"чистая" ссылка>
http://thedailywtf.com/Articles/Out-of-All-the-Possible-Answers.aspx

Это прекрасно, я считаю.

for ($i=1;$i<=99999999999;$i++) { 
  $num = 20*$i;
  if ($num%19 == 0) {
    if ($num%18 == 0) {
      if ($num%17 == 0) {
        if ($num%16 == 0) {
          if ($num%15 == 0) {
            if ($num%14 == 0) {
              if ($num%13 == 0) {
                if ($num%12 == 0) {
                  if ($num%11 == 0) {  
                    if ($num%9 == 0) {
                      if ($num%8 == 0) {
                        if ($num%7 == 0) {
                          if ($num%6 == 0) {
                            if ($num%3 == 0) {
                              echo $num;
                              exit();
                            }
                          }
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

---
Я не пойму искали разработчика кодера или системного аналитика? :) 20.10.08 22:59  
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>
Senior developer-а 21.10.08 00:16  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
То говно, что было приведено не катит даже на джуниора. Ибо кто после него это разгребать будет
Я тоже так считаю. Хотя опытный кодер дложен знать... 20.10.08 12:07  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> http://thedailywtf.com/Articles/Out-of-All-the-Possible-Ans
> wers.aspx
>
> Это прекрасно, я считаю.

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

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

#include <time.h>
#include <stdio.h>

int main( void ){

  long t = clock();
  for( long i = 20; i<=1000000000; i += 20 ){ 
    if( i % 19 == 0 ){
      if( i % 17 == 0 ){
        if( i % 13 == 0 ){
          if( i % 11 == 0 ){
            if( i % 7 == 0 ){
              if( i % 3 == 0 ){
                printf( "%lu (%f sec.)\n", i, ( clock() - t ) / CLK_TCK );
                return 0;
              }
            }
          }
        }
      }
    }
  }
  return 0;
}

---

19399380 (0.000000 sec.)
Для школьника достаточно 20.10.08 21:33  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Для профессионального разработчика - нет.

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

Во первых алгоритм не супер-пупер, а самое логичное решение. Во вторых именно на алгоритм и надо смотреть, а не на решение. Брут-форс - не алгоритм (ну, формально, конечно, алгоритм, но думаю ты понял что я имею в виду).

> особенно для профессионала. Самое лучшее решение - это
> быстро написаное и достаточно быстро считающее. Еще

Нет. Собеседование (особенно на senior-позицию) не олимпиада, в которой тебе добавят баллы за любое решение, выдающее правильный результат. Я проводил немало собеседований, но таких задач не задавал вообще, ибо большинство претендентов не могут осилить даже элементарнейшую задачу реверса односвязного списка за O(const) памяти, не говоря уж о задачах, требующих знания ШКОЛЬНОГО курса математики. На собеседованиях пытаются оценить потенциал претендента. То бишь если он чего не знает - научить не проблема, если мозги есть, а вот если нет мозгов - сразу нахрен, даже если знает наизусть всю стандартную библиотеку похапэ.

> профессионал должен выбирать инструментарий, адекватный
> решаемой задаче.

Суть таких задач не в том, чтобы ты ее решил любой ценой, а чтобы продемонстрировал свою способность МЫСЛИТЬ. Причем некоторые задачи вообще не имеют "правильного" ответа (круглые канализационные люки) или имеют ответ, который можно только знать (узнать в каком нибудь справочнике), но невозможно угадать (масса боинга, количество заправок, прибыль телеком компаний). Здесь гораздо четче просматривается цель этих задач. Ответить правильно, если ты специально не заучил все цифры из справочников, у тебя нет никакой возможности ПРИНЦИПИАЛЬНО. Поэтому расслабься и начинай думать.

> Что-то ментя это настолько затронуло, что я захотел
> проверить насколько я могу ошибиться. Подумал, что этот
> алгоритм может считать за время не больше секунды. Ошибся.
> Правда чуть оптимизировал исходный алгоритм (выкинул все
> непростые), но время не превысило десятых долей секунды.
Хехе. Просто перемножить все простые (число Эвклида) недостаточно (к тому же ты выкинул двойку). Число должно делиться не на 2, а на 16, не на 3, а на 9. С ростом N число таких степеней возрастает.

Вот решение на C:
#include <stdio.h>
#include <gmp.h>

int main(int argc, char **argv) {
    mpz_t res;
    mpz_init_set_ui(res, 1);
    for(int x=1; x<=1000; x++) {
        mpz_lcm_ui(res, res, x);
    };
    mpz_out_str (stdout, 10, res);
};

---

Как видишь оно считает решение той же задачи для N == 1000. Давай на том же собеседовании это будет следующим вопросом :-). Вполне обоснованный вопрос к профессиональному разработчику: насколько легко твое решение следует за изменяющимися требованиями (это, в общем, один из основных вопросов, ибо требования меняются постоянно)
70ые годы ? Мы пишем алгоритмы ? 23.10.08 16:55  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
А я то, наивный, думал что мы зарабатываем деньги. А количество денег в мире - величина постоянная, без всяких там O. (ссук государств просто так печатающих бумажки в этой модели нет)
Вывод: зарабатывание денег - это перекладывание их из кармана заказчика, в карман разработчика.
А заказчику обычно пох. какой алгоритм ты использовал. Ему вчера надо запустить твою систему. И пока ты будешь придумывать свои алгоритмы - он проворонит заказ, и в его кармане не будет бабла. А нет бабла в его кармане - нет в твоем.
Так что хорошие алгоритмы - это конечно не плохо, но красная икра каждый вечер, бабы и загранки хотя бы пару раз в год - перевешивают.
ИМХО сейчас программер должен обладать скиллом удовлетворения заказчика. А все остальное уже написано до нас... вернее нами, но десять лет назад :)
Какое наикрутейшее заблуждение!... 25.10.08 13:09  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
> А я то, наивный, думал что мы зарабатываем деньги. А
> количество денег в мире - величина постоянная, без всяких
> там O. (ссук государств просто так печатающих бумажки в
> этой модели нет)

Какое наикрутейшее заблуждение!...
Деньги никак не могут быть постоянной величиной даже в случае, если все страны мира будут привязывать валюту к своему золотому запасу, так как золотой запас имеет свойство увеличиваться или, в редких случаях, уменьшаться.
Привязку валюты к золотому запасу никто не делает уже около 100 лет. Сейчас денежная масса обычно привязывается к ВВП, соответственно, уменьшение ВВП относительно ден.массы или увеличение ден.массы относительно ВВП или снижение стоимости ВВП на мировых биржах приводит к инфляции в стране. И наоборот...

> Вывод: зарабатывание денег - это перекладывание их из
> кармана заказчика, в карман разработчика.

Если бы все было так просто... :))

> А заказчику обычно пох. какой алгоритм ты использовал. Ему
> вчера надо запустить твою систему. И пока ты будешь
> придумывать свои алгоритмы - он проворонит заказ, и в его
> кармане не будет бабла. А нет бабла в его кармане - нет в
> твоем.

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

> Так что хорошие алгоритмы - это конечно не плохо, но
> красная икра каждый вечер, бабы и загранки хотя бы пару раз
> в год - перевешивают.
> ИМХО сейчас программер должен обладать скиллом
> удовлетворения заказчика. А все остальное уже написано до
> нас... вернее нами, но десять лет назад :)
"Всякие там O" нужны как раз для того, чтобы писать... 23.10.08 23:25  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> А я то, наивный, думал что мы зарабатываем деньги. А
> количество денег в мире - величина постоянная, без всяких
> там O. (ссук государств просто так печатающих бумажки в
> этой модели нет)

"Всякие там O" нужны как раз для того, чтобы писать ПРОГРАММЫ, а не говно. Есть очень высокая вероятность, что данный конкретный похапешник напишет говно.

> А заказчику обычно пох. какой алгоритм ты использовал. Ему

Ага, главное что работало. Только "работало" это не всегда выдавало правильный результат.

> вчера надо запустить твою систему. И пока ты будешь
> придумывать свои алгоритмы - он проворонит заказ, и в его
> кармане не будет бабла. А нет бабла в его кармане - нет в
> твоем.
Лучше вообще не выходить на рынок, чем выходить с говном. Именно в первый выход на рынок складывается "общественное мнение" о твоем продукте, которое потом довольно сложно изменить. Кроме оставшихся в истории сообщений на форумах, обзоров в каталогах, отзывах в этих каталогах и т.п., если у тебя index.php будет делать миллион запросов к базе и будет выдерживать маскимум 5 посетителей в минуту - тебя еще и гугль штрафанет и хостер забанит.

Ты до сих пор считаешь, что произвести НЕБОЛЬШУЮ оптимизацию кода дороже, чем нести убытки от говеного продукта?

> Так что хорошие алгоритмы - это конечно не плохо, но
> красная икра каждый вечер, бабы и загранки хотя бы пару раз
> в год - перевешивают.
Хехе. У тебя совершенно превратное мнение о заказчиках. В нормальную контору такого быдлокодера не возьмут, на фриланссайте он получит кучу хреновых отзывов (даже не от программистов, а просто от заказчиков, у которых сайты не будут справляться даже с минимальной нагрузкой). Откуда деньги то? Только потому что у тебя есть тонна быдлокода, на которую затрачен минимум ресурсов еще не значит, что ты сможешь его продать.

> ИМХО сейчас программер должен обладать скиллом
> удовлетворения заказчика. А все остальное уже написано до
> нас... вернее нами, но десять лет назад :)
Code-monkey - это не программист. Такой "программер" НЕ СМОЖЕТ удовлетворить заказчика. Банально потому, что его говно будет еле шевелиться, когда его развернут, ибо программер в первую очередь должен МОЗГИ (граммар наци идут лесом) иметь и именно мозги являются его орудием труда, а не компьютер или клавиатура, как считают некоторые.
Не, как раз работало - это выдавало правильный результат :) 24.10.08 19:04  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
> Ага, главное что работало. Только "работало" это не всегда
> выдавало правильный результат.

Не, как раз работало - это выдавало правильный результат :)

>
> > вчера надо запустить твою систему. И пока ты будешь
> > придумывать свои алгоритмы - он проворонит заказ, и в
> его
> > кармане не будет бабла. А нет бабла в его кармане -
> нет в
> > твоем.
> Лучше вообще не выходить на рынок, чем выходить с говном.
> Именно в первый выход на рынок складывается "общественное
> мнение" о твоем продукте, которое потом довольно сложно
> изменить. Кроме оставшихся в истории сообщений на форумах,
> обзоров в каталогах, отзывах в этих каталогах и т.п., если
> у тебя index.php будет делать миллион запросов к базе и
> будет выдерживать маскимум 5 посетителей в минуту - тебя
> еще и гугль штрафанет и хостер забанит.

Так это говорит о том, что система не работает :) Работает - это когда заказчик доволен. А если его сайт забанили, штрафы начислили и вообще все плохо - вряд ли он будет доволен.

> Ты до сих пор считаешь, что произвести НЕБОЛЬШУЮ
> оптимизацию кода дороже, чем нести убытки от говеного
> продукта?

Небольшую - да, однако в говеных продуктах небольшой оптимизацией вряд ли обойдешься :(
А в не говеных, оптимизировать миллисекунды - смысла не имеет :) Как пример, можно написать супер пупер оптимизированый контейнер, аналог std::string. А нафига ? Затраты на такую оптимизацию будут несравненно большими по сравнению с результатом.

>
> > Так что хорошие алгоритмы - это конечно не плохо, но
> > красная икра каждый вечер, бабы и загранки хотя бы
> пару раз
> > в год - перевешивают.
> Хехе. У тебя совершенно превратное мнение о заказчиках. В
> нормальную контору такого быдлокодера не возьмут, на
> фриланссайте он получит кучу хреновых отзывов (даже не от
> программистов, а просто от заказчиков, у которых сайты не
> будут справляться даже с минимальной нагрузкой). Откуда
> деньги то? Только потому что у тебя есть тонна быдлокода,
> на которую затрачен минимум ресурсов еще не значит, что ты
> сможешь его продать.

К сожаленью сможешь :( Это предложение не относится к моему ответу типа "зачем придумывать супер-пупер-высшего качества в течении полу-года, когда можно взять супер-хорошего качества и выдать продукт "вчера" " - именно об этом я сказал.
А насчет продажи полного говона... К сожаленью продается. И хорошо идет.
Кстати, если забить на совесть и профессиональную честь, то получается: продажа говна - дело более выгодное чем продажа конфетки. Все дело в правильно составленном договоре.
Продашь говно, а потом еще срубишь в десять раз больше бабла на его поддержке. И это не шутка.

>
> > ИМХО сейчас программер должен обладать скиллом
> > удовлетворения заказчика. А все остальное уже написано
> до
> > нас... вернее нами, но десять лет назад :)
> Code-monkey - это не программист. Такой "программер" НЕ
> СМОЖЕТ удовлетворить заказчика. Банально потому, что его
> говно будет еле шевелиться, когда его развернут, ибо
> программер в первую очередь должен МОЗГИ (граммар наци идут
> лесом) иметь и именно мозги являются его орудием труда, а
> не компьютер или клавиатура, как считают некоторые.

Да, и опять философия. Мозгами надо подумать что важней:
1. Амбиции - мы сделаем супер пупер классную систему
2. Амбации+Жадность - мы сделаем хорошую систему и срубим больше бабла
3. Жадность - мы срубим бабло сейчас
4. Супер-Жадность - сейчас мы срубим бабло, а потом будем доить наших коров.

Так что еще не известно а нужно ли делать супер-пупер конфетки...
Если уж ты расширяешь понятие "правильный результат" 24.10.08 21:56  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Не, как раз работало - это выдавало правильный результат :)
Еще и приемлемым временем, нагрузкой и пр., то говно в корне - неправильное. Оно выдает правильный результат ТОЛЬКО если под правильным результатом понимать выхлоп после ее работы и ничего больше


> Так это говорит о том, что система не работает :) Работает
> - это когда заказчик доволен. А если его сайт забанили,
Заказчик принимает заказ после функциональных тестов в лучшем случае. %опы выясняется когда он выпускает систему в продакшн.

> > Ты до сих пор считаешь, что произвести НЕБОЛЬШУЮ
> > оптимизацию кода дороже, чем нести убытки от говеного
> > продукта?

> Небольшую - да, однако в говеных продуктах небольшой
> оптимизацией вряд ли обойдешься :(
Ага, выкинуть и переписать нормально. А ведь это только оптимизация. Рынок же не только диктует требования к производительности, но и постоянно меняет требования к функционалу. Что теперь для добавления нового функционала (или изменения старого) нужно будет все переписывать? Лучше вообще не нанимать человека, который не в состоянии писать maintainable код. Даже за бесплатно - в итоге дороже выйдет. Код в корне помимо того, что тормозной еще и ни хрена не мейнтейнабл.

> А в не говеных, оптимизировать миллисекунды - смысла не
> имеет :) Как пример, можно написать супер пупер
> оптимизированый контейнер, аналог std::string. А нафига ?
> Затраты на такую оптимизацию будут несравненно большими по
> сравнению с результатом.
Это смотря в каком приложении. Если профайлер показывает, что основные тормоза в стринге - его нужно оптимизировать. А систему изначально писать с учетом ВОЗМОЖНЫХ оптимизаций.

> К сожаленью сможешь :( Это предложение не относится к моему
Единичные случаи. Если бы я не работал в конторах, которые пытались вывести свои продукты на рынок - я бы не говорил. Даже если быдлокод будет работать и жрать при этом приемлемое количество времени, он не сможет изменяться "малой кровью". То есть на рынок может и выйдут, но вряд ли удержатся.

> А насчет продажи полного говона... К сожаленью продается. И
> хорошо идет.
Нет не продается. И не идет. Единичные случаи захвата востребованной, но почему то все еще полностью свободной ниши - не в счет. В остальных случае тебе придется конкурировать. Быдлокод неконкурентноспособен.

> Кстати, если забить на совесть и профессиональную честь, то
> получается: продажа говна - дело более выгодное чем продажа
> конфетки. Все дело в правильно составленном договоре.
Лучше перепродавать доставшиеся по дешевке конфетки (open source с приемлемыми лицензиями себе утаскивать или еще чего). Быдлокод в большинстве случае не продается. Говорю по собственному опыту.

> Продашь говно, а потом еще срубишь в десять раз больше
> бабла на его поддержке. И это не шутка.
Поддержке? Да ты на ней разоришься, а не бабла срубишь :-)

> Так что еще не известно а нужно ли делать супер-пупер
> конфетки...
Речь не о конфетках. Человек, хотя бы раз попытавшийся поддерживать кучу своего говнокода (а со скилам к правильному программированию не рождаются - практически все начинающие программисты быдлокодят) сразу понимает, как надо БЫЛО сделать, чтобы проект можно было сдвинуть в нужную сторону. Следующий проект уже делается с учетом таких требований. Если говорить о затратах времени до выхода на рынок, то по моему опыту профессионал пишет даже быстрее (в основном за счет использования своих же наработок из прошлых проектов или даже использования чужих, а быдлокодеры почему то всегда изобретают собственные велосипеды) и на выходе у него получается более поддерживаемый код.
Слушай, а чего ты такой занудный ? 24.10.08 23:50  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
Ты название конфы читать умеешь ? :)
Нет ты :-) 24.10.08 23:52  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Это ты начал говорить, что говнокод в принципе и не говно.
smile 25.10.08 01:42  
Автор: PS <PS> Статус: Elderman
Отредактировано 25.10.08 01:53  Количество правок: 2
<"чистая" ссылка>
Говно-код - это очень полезная весч, при правильном применении :)
Навоз тоже жрать не нужно, но он прекрасно подходит для удобрения полей :) На котором растет жратва ;)
:) Последнее утверждение не лишено здравого смысла. +1 25.10.08 13:13  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Хы, вот например, сельским хозяйством человечество занимается тысячелетиями, а селлекция всё еще актуальна. странно? hint: прогресс. 23.10.08 19:34  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
А нужно ли оно, такое собеседование. Во многих конторах... 21.10.08 11:58  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 21.10.08 12:23  Количество правок: 1
<"чистая" ссылка>
> Нет. Собеседование (особенно на senior-позицию) не
> олимпиада, в которой тебе добавят баллы за любое решение,
> выдающее правильный результат. Я проводил немало
> собеседований, но таких задач не задавал вообще, ибо
> большинство претендентов не могут осилить даже
> элементарнейшую задачу реверса односвязного списка за
> O(const) памяти, не говоря уж о задачах, требующих знания
> ШКОЛЬНОГО курса математики. На собеседованиях пытаются
> оценить потенциал претендента. То бишь если он чего не
> знает - научить не проблема, если мозги есть, а вот если
> нет мозгов - сразу нахрен, даже если знает наизусть всю
> стандартную библиотеку похапэ.

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

> Суть таких задач не в том, чтобы ты ее решил любой ценой, а
> чтобы продемонстрировал свою способность МЫСЛИТЬ. Причем

Ну не везде у нас любят мыслящих (слишком умных).

> некоторые задачи вообще не имеют "правильного" ответа
> (круглые канализационные люки) или имеют ответ, который
> можно только знать (узнать в каком нибудь справочнике), но
> невозможно угадать (масса боинга, количество заправок,
> прибыль телеком компаний). Здесь гораздо четче
> просматривается цель этих задач. Ответить правильно, если
> ты специально не заучил все цифры из справочников, у тебя
> нет никакой возможности ПРИНЦИПИАЛЬНО. Поэтому расслабься и
> начинай думать.

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

> Хехе. Просто перемножить все простые (число Эвклида)
> недостаточно (к тому же ты выкинул двойку). Число должно
> делиться не на 2, а на 16, не на 3, а на 9. С ростом N
> число таких степеней возрастает.

Правильно, второпях перевернул все с ног на голову. Если уж идем с шагом 20, то нет смысла проверять деление на 10, на 5 и на 2. Причем в исходной программе именно этих чисел и не было. В принципе сократить IFы в несколько раз уже приятно, хотя бы те, что чаще всего выполняются (внешние). С другой стороны вложеные IFы это не вложеные FORы.

> Вот решение на C:
>
#include <stdio.h>> #include <gmp.h>
> 
> int main(int argc, char **argv) {
>     mpz_t res;
>     mpz_init_set_ui(res, 1);
>     for(int x=1; x<=1000; x++) {
> 	mpz_lcm_ui(res, res, x);
>     };
>     mpz_out_str (stdout, 10, res);
> };

---
>
> Как видишь оно считает решение той же задачи для N == 1000.
> Давай на том же собеседовании это будет следующим вопросом
> :-). Вполне обоснованный вопрос к профессиональному
> разработчику: насколько легко твое решение следует за
> изменяющимися требованиями (это, в общем, один из основных
> вопросов, ибо требования меняются постоянно)

Есть конкретная задача, есть и конкретное решение. Если задача решается брютфорсом, причем время написания 5 минут и работать она будет ~5 микросекунд, то писать ее нужно именно так, а не убивать на разработку самого совершенного алгоритма 5 дней.
Я бы с тобой как обычно поспорил бы :) 21.10.08 10:50  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
Собеседование - это для интервьюируваемого определенный стресс. Даже очень умный человек может растеряться от немного необычной постановки задачи и сесть в лужу, и даже полный дурак может сосредоточиться и решить недоступную его мозгам в обычных условиях задачу. Это раз.

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

Даже не в состоянии стресса (а просто спать хочется) я вот сейчас прочитав твой пост пропустил, что реверс списка должен быть за O(const) по памяти, и сильно удивился, зная, что реверс списка может быть проведен лишь за O(N) по времени. Я не дурак - просто в определенных ситуациях (скажем, человек ехал на собеседование на электричке из другого штата пять часов) может быть погрешность в работе мозгов. Погрешность эта весьма велика для большинства человек. Это три.

Человеческое мышление, еще раз, очень сложно. Вот задача со стеклянными шарами: кидаем со 100-этажного здания стеклянные шары, надо узнать начиная с какого этажа шары начнут биться. Надо найти наибыстрейший алгоритм при наличии двух шаров. Дурак пропустит мимо ушей слово "наибыстрейший", и будет кидать шары с первого, пока не дойдет до номера этажа. Потом будет чесать репу и думать зачем нужен второй шар. Математик же, зная, что множество этажей упорядочено по принципу "бьется-не бьется" и надо найти наискорейший алгоритм, кинет шар сразу по методу дихотомии с пятидесятого этажа и шар разобьется. Математик подумает, что это подъебка, и скажет, что задачу нельзя решить (я однажды так и сказал на собеседовании, не спав перед собеседованием двое суток, ибо играл в стрип-покер). Даже если математику подсказать решение, то он может отказаться от нахождения производной, ибо знает, что потом придется решать уравнение, а это чаще всего занимает много времени (если он видел задачки сложнее чем в учебнике). Это четыре.

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


Ну а по поводу senior php'шника, в принципе, его алгоритм безусловно плох, и я банально не верю, что у него 10 лет разработки за плечами. Однако если говорить о подходе, то если мне на собеседовании зададут написать дерево поиска, то я не буду писать АВЛ-дерево, а если зададут отсортировать массив, то я применю метод прямого выбора либо пузырька. Я знаю и о других алгоритмах, но пока у меня нет в них необходимости, я не буду их писать.

В нашей компании был такой случай - программисту надо было на КПК'шной версии продукта нарисовать кнопку со стрелочкой ">". Так как экран можно "перевернуть", то и знак на кнопке можно перевернуть. За четрые дня он написал алгоритм преобразования битмапы используя умножение на матрицу (он слегка подзабыл теорию, поэтому провозился долго). Скажем, даже если бы это было эффективней, чем подставить бникодовский символ в кнопочку, или уж если работать с битмапой, то просто сделать тупо в цикле ряд swap-пов, это все равно плохое решение. Потому что долгое и неоправданно сложное. Поэтому стремление программиста всегда найти "лучшее" решение меня лично очень настораживает.
Стрессоустойчивоть - одно из требований к соискателям. Как... 21.10.08 11:54  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Собеседование - это для интервьюируваемого определенный
> стресс. Даже очень умный человек может растеряться от
Стрессоустойчивоть - одно из требований к соискателям. Как же сорванные сроки, постоянно изменяющиеся требования, риск увольнения и т.п.? Если по любой из этих причин ты начнешь писать говно из корневого поста - ты не нужен. Встречал статью про российскую компанию, где тупо выливали в лицо стакан воды еще до начала собеседования (после этого я бы отказался от собеседования вообще). В более умных конторах, к примеру, интервьюер постоянно кривится, вздыхает и всячески дает понять, что ты несешь полную чушь. Умение аргументированно отстаивать свою позицию (в том числе перед начальством) - тоже очень ценный скилл.

> Мозг человека весьма сложно устроен. Оценивать задачки по
> принципу "решил-не решил" нельзя. Скажем, лично я
Абсолютно с тобой согласен. Именно поэтому два неправильных решения, представленные в данном посте в мульйон раз лучше, правильного в корневом сообщении.

> достаточно медленно соображаю. Тем не менее, если дать мне
> несколько больше времени, то я прихожу к решениям, к
> которым большинство других быстро-соображающих не могут
> прийти в принципе. Результирующая скорость и качество
Я такой же. На интервью смотрят за ходом твоих размышлений. Если ты молча продумаешь полчаса, то интервьер не будет тебя ждать (ибо в период молчания ты ничем не будешь отличаться от просто дурака, но узнать чего же ты стоишь все таки надо). Он даст тебе твои полчаса на задачу, если ты сходу начнешь РАССУЖДАТЬ, если же ты будешь сидеть молча - он перейдет к другой задача. Просто чтобы дать ТЕБЕ шанс показать себя

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

> Даже не в состоянии стресса (а просто спать хочется) я вот
> сейчас прочитав твой пост пропустил, что реверс списка
[skipped]
> часов) может быть погрешность в работе мозгов. Погрешность
> эта весьма велика для большинства человек. Это три.
Вменяемый интервьер это 1. Понимает 2. Ему это не важно.
Я вот на собеседовании в МС тоже решил не ту задачу, которую мне дали. Меня во-первых выслушали (а хули - все равно ж за решением какой задачи следить, главное посмотреть КАК человек ее решает), во-вторых после этого уточнили исходное условие и посмотрели как я решу уже ее

> Человеческое мышление, еще раз, очень сложно. Вот задача со
> стеклянными шарами: кидаем со 100-этажного здания
> стеклянные шары, надо узнать начиная с какого этажа шары
ОЯЕБУ. А что эту задачу дают на собеседованиях? Это ж паззл чистейшей воды, действительно не имеющий отношения к программированию. Лично я тупил над ней несколько часов - никакого собеседования не хватило бы. Я сходу могу привести еще несколько подобных задачек.

> Все задачи разноплановые. Вот лично у меня не особо хорошо
> мозги работают в сторону дискретной математики и вообще
> практически не умеют решать геометрию, зато замечательно
> воспринимают математику непрерывную, а так же теорию
> вероятностей. Задашь мне простейшую задачку по геометрии -
Парадокс Монти-Холла наверное знаешь. Как раз по теорверу.

> придешь к выводу, что я полный идиот. Задашь мне весьма
> трудную задачу по терверу - придешь к выводу, что
> гениальный мальчик. А на самом деле я всего лишь
> посередине. То есть задание задачек - это со статистической
> точки зрения не совсем корректный метод оценки
> интеллектуального потенциала человека. Это пять.
Поэтому надо давать много задач. Как имеющих конкретное решение так и просто "на поговорить".

> Ну а по поводу senior php'шника, в принципе, его алгоритм
> безусловно плох, и я банально не верю, что у него 10 лет
> разработки за плечами. Однако если говорить о подходе, то
> если мне на собеседовании зададут написать дерево поиска,
> то я не буду писать АВЛ-дерево, а если зададут
АВЛ - устаревшее говно. RB-деревья рулят :-)

> отсортировать массив, то я применю метод прямого выбора
> либо пузырька. Я знаю и о других алгоритмах, но пока у меня
> нет в них необходимости, я не буду их писать.
Ну как минимум надо указать, что ты о них знаешь. Опять таки из личного опыта: на одну из задачек я словами сказал: "Проверку входных параметров выполнять не будем, потому как задача то синтетическая, а это только увеличит размер", на что получил ответ: "ОК, но хорошо что ты об этом упомянул, иначе я бы сам спросил".

> В нашей компании был такой случай - программисту надо было
> на КПК'шной версии продукта нарисовать кнопку со стрелочкой
> ">". Так как экран можно "перевернуть", то и знак на
> кнопке можно перевернуть. За четрые дня он написал алгоритм
> преобразования битмапы используя умножение на матрицу (он
> слегка подзабыл теорию, поэтому провозился долго). Скажем,
Хм, я тоже "подзабыл" и сходу не придумал как можно транспонировать матрицу умножением. Полез в http://en.wikipedia.org/wiki/Transpose и тоже ничего подобного не обнаружил. Что то мне подсказывает, что это 1. Невозможно 2. Ненужно, ибо транспонирование матрицы гораздо более простая операция, чем умножение матриц.

> сложное. Поэтому стремление программиста всегда найти
> "лучшее" решение меня лично очень настораживает.
Вот именно поэтому его решение и не было лучшим. Может быть оно было самым гибким, но этого не требовала задача.
Бугога — это я про российскую компанию и стакан воды в лицо на интервью — интересует статистика ;-) 22.10.08 11:44  
Автор: HandleX <Александр Майборода> Статус: The Elderman
<"чистая" ссылка>
Subj, а именно:
Сколько раз интервьюверу в ответ на сие действо:
1) съездили по рылу;
2) плюнули в морду;
3) подали в суд за оскорбление действием.

Я бы на таком интервью... хз. Поразмышлял бы, что сделать ;-)
Перечисленное тобой - это признаки очень плохого менеджмента... 21.10.08 15:34  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
> Стрессоустойчивоть - одно из требований к соискателям. Как
> же сорванные сроки, постоянно изменяющиеся требования, риск
> увольнения и т.п.? Если по любой из этих причин ты начнешь
Перечисленное тобой - это признаки очень плохого менеджмента в компании. Я бы в такой компании не хотел работать. К тому же стрессоустойчивость человека - вещь безусловно важная, но не единственная. Как ты застрахуешься от того что он не будет, например, банально медленно работать, просиживая рабочее время в Интернете? Стрессоустойчивость - это уже несколько из другой области, и не надо увязывать ее с результатом решения задачи.

> Я такой же. На интервью смотрят за ходом твоих размышлений.
> Если ты молча продумаешь полчаса, то интервьер не будет
> тебя ждать (ибо в период молчания ты ничем не будешь
> отличаться от просто дурака, но узнать чего же ты стоишь
> все таки надо). Он даст тебе твои полчаса на задачу, если
> ты сходу начнешь РАССУЖДАТЬ, если же ты будешь сидеть молча
> - он перейдет к другой задача. Просто чтобы дать ТЕБЕ шанс
> показать себя
Многим людям мешает рассуждение вслух, например. Рассуждать можно, если задали задачу достаточно общего толку, типа: как бы ты стал писать интерпретатор? С целесообразностью послушать такие рассуждения я вполне согласен. Над задачей же которую предлагается именно решить, часто не порассуждаешь. Как в той же задаче со стеклянными шарами.

> Бывают, но не довольно редко. Вот данную конкретную задачу
> лично я решил довольно быстро. После некоторых размышлений
> этот алгоритм оказался идеальным для не очень больших чисел
Ну это все же достаточно простая задача, которая решается последовательно. Здесь не может быть никакой загвоздки, если человек знаком с арифметикой. Задачи такого уровня не показывают интеллект - только лишь отсеивают совсем баранов.

> ОЯЕБУ. А что эту задачу дают на собеседованиях? Это ж паззл
> чистейшей воды, действительно не имеющий отношения к
> программированию. Лично я тупил над ней несколько часов -
> никакого собеседования не хватило бы. Я сходу могу привести
> еще несколько подобных задачек.
Да, реальный случай, в крупной компании. Но там у них вообще много интересного было.

> Парадокс Монти-Холла наверное знаешь. Как раз по теорверу.
Да, знаю. Хотя не понял при чем он здесь. До решения конечно трудно додуматься сразу, но эта задача в своем роде уникальная. Сколько я не искал подобных задачь по терверу - все остальные решаются достаточно просто.

> АВЛ - устаревшее говно. RB-деревья рулят :-)
Может быть. Я не знаток деревьев.

> Хм, я тоже "подзабыл" и сходу не придумал как можно
> транспонировать матрицу умножением. Полез в
> http://en.wikipedia.org/wiki/Transpose и тоже ничего
> подобного не обнаружил. Что то мне подсказывает, что это 1.
> Невозможно 2. Ненужно, ибо транспонирование матрицы гораздо
> более простая операция, чем умножение матриц.
Я вероятно не так немного выразился. Он не матрицу транспонировал, а вычислял новые координаты точек через умножение на матрицу поворота. Это конечно вырожденный клинический случай, но он показателен. Я не раз видел как программисты тратили несколько дней на "оптимизацию" и разработку совершенно не критичных вещей, и в результате рождали такое говно, которое падало через раз. Причем на этапе разработки, когда еше никаких проблем с производительностью не начиналось. Вот поэтому склонность к поиску оптимальных решений меня несколько смущает.
1  |  2  |  3 >>  »  






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach