Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Что именно? Сорванные сроки? Ну дык вон тот же MS... 21.10.08 21:18 Число просмотров: 3610
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 21.10.08 21:18 Количество правок: 1
|
> Перечисленное тобой - это признаки очень плохого
> менеджмента в компании. Я бы в такой компании не хотел
Что именно? Сорванные сроки? Ну дык вон тот же MS сертифицированный по Capability Maturity Model Level 5 насколько я знаю, и тот сорвал сроки по Висте. Сорванные сроки - результат изменяющихся требований, а требования меняет РЫНОК, а не менеджмент. Риск увольнения есть в любой компании, независимо от качества менеджмента.
> работать. К тому же стрессоустойчивость человека - вещь
> безусловно важная, но не единственная. Как ты застрахуешься
> от того что он не будет, например, банально медленно
> работать, просиживая рабочее время в Интернете?
Никак. Не выполняет взятых обязательств - прости-прощай. А выполняет - пусть хоть часами порнуху смотрит и вообще в офис не ходит.
> Стрессоустойчивость - это уже несколько из другой области,
> и не надо увязывать ее с результатом решения задачи.
Это не я начал увязывать стресс с задачей. Разработчику В ЛЮБОМ СЛУЧАЕ придется рано или поздно работать в условиях стресса. Независимо от качества менеджмента. Он может начать работать медленее, может давать ЧУТЬ менее качественный код, но если из него начнет выходить говно, подобное приведенному выше - я бы с ним работать не захотел. Ни как менеджер ни как разработчик
> Многим людям мешает рассуждение вслух, например. Рассуждать
> можно, если задали задачу достаточно общего толку, типа:
> как бы ты стал писать интерпретатор? С целесообразностью
Ну вот задача интервьюера как раз таки и найти задачу, над которой ты сможешь порассуждать. Ты (вернее грамотный сотрудник) ему нужен в общем ненамного меньше чем он тебя и поэтому слишком жесткая позиция неуместна. Почитай к примеру про собеседования в тот же МС - практически у всех, кто его проходил, независимо от результата, остается хорошее впечатление.
> послушать такие рассуждения я вполне согласен. Над задачей
> же которую предлагается именно решить, часто не
> порассуждаешь. Как в той же задаче со стеклянными шарами.
Почему же. Можно к примеру для начала найти субоптимальное решение (для 20-ти бросков оно тривиально), а потом пытаться оптимизировать.
> Ну это все же достаточно простая задача, которая решается
> последовательно. Здесь не может быть никакой загвоздки,
> если человек знаком с арифметикой. Задачи такого уровня не
> показывают интеллект - только лишь отсеивают совсем
> баранов.
Да загвоздок тут как минимум две. С другой стороны надо дать как можно больше "ортогональных" задачек, чтобы по этому базису примерно представить что ты из себя представляешь. И лучше не давать откровенные паззлы, как с шарами, а достаточно тривиальные, но с которыми человек с мозгами справится, а без оных - накатает самое очевидное решение, которое окажется самым говеным.
> Да, реальный случай, в крупной компании. Но там у них
> вообще много интересного было.
Хм. По моему не очень удачная задача. В приемлемые (для собеседования) сроки ее можно решить только если ты уже знаешь ответ. В конце концов они наберут людей, которые знают много паззлов, а не программистов.
> > Парадокс Монти-Холла наверное знаешь. Как раз по
> теорверу.
> Да, знаю. Хотя не понял при чем он здесь. До решения
Ты сказал, что отлично щелкаешь задачи по теорвер. Вот на этом парадоксе срезалось немало светил теорвера. Если бы не знал - я бы тебе его задал и посмотрел :-)
> > АВЛ - устаревшее говно. RB-деревья рулят :-)
> Может быть. Я не знаток деревьев.
Да пошутил я. Просто лично я смогу на интервью набросать хотя бы общую структуру RB-дерева, потому что вижу какая логика за ним стоит, а вот АВЛ я не понимаю и зубрить не хочу. По моему у Сейджвика читал, что АВЛ не гарантируют логарифмическое время операций для худшего случая, заглянул в вики - написано что гарантируют и при этом высота в среднем процентов на 20 меньше, чем у RB.
> Я вероятно не так немного выразился. Он не матрицу
> транспонировал, а вычислял новые координаты точек через
> умножение на матрицу поворота. Это конечно вырожденный
Ухты. Поточечно вычислял координату новой точки. Это да, сильно.
> клинический случай, но он показателен. Я не раз видел как
> программисты тратили несколько дней на "оптимизацию" и
"Преждевременная оптимизиация - корень всех бед" Энтони Хоар
Но как я уже сказал, это и не оптимизация вовсе, ибо человек не понял чего же он родил. Сложность примененного алгоритма не имеет ничего общего с его оптимальностью. Оптимальным в данном случае был precalculation (то есть хранение всех вариантов битмапа).
Кстати, уж какие упрощенные требования я ни предъявлял к соискателям (что поделаешь в нашем селе нанять бы хотя бы вменяемого, а не заниматься поиском бриллиантов), когда проводил собеседования, сложность основных операций над стандартными контейнерами я спрашивал ОБЯЗАТЕЛЬНО. Причем именно в O-нотации. Человек не знающий даже этого - вообще не программист. В реальных проектах такие товарищи склонны в лучшем случае к квадратичным решениям, но бывали случае экспоненциальных и даже факториальных.
> разработку совершенно не критичных вещей, и в результате
> рождали такое говно, которое падало через раз. Причем на
> этапе разработки, когда еше никаких проблем с
> производительностью не начиналось. Вот поэтому склонность к
> поиску оптимальных решений меня несколько смущает.
На этапе разработки оптимизация сводится к построению наиболее гибкого фреймворка, на котором уже и решается задача. Главное, чтобы любую часть реализации можно было оптимизировать по результатам профилирования не затрагивая остальной код.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
