информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Сетевые кракеры и правда о деле ЛевинаАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Phrack #70/0x46 
 Возможно, Facebook наступил на... 
 50 лет электронной почте 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / humor
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Что именно? Сорванные сроки? Ну дык вон тот же MS... 21.10.08 21:18  Число просмотров: 3017
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 21.10.08 21:18  Количество правок: 1
<"чистая" ссылка>
> Перечисленное тобой - это признаки очень плохого
> менеджмента в компании. Я бы в такой компании не хотел
Что именно? Сорванные сроки? Ну дык вон тот же MS сертифицированный по Capability Maturity Model Level 5 насколько я знаю, и тот сорвал сроки по Висте. Сорванные сроки - результат изменяющихся требований, а требования меняет РЫНОК, а не менеджмент. Риск увольнения есть в любой компании, независимо от качества менеджмента.

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

> Стрессоустойчивость - это уже несколько из другой области,
> и не надо увязывать ее с результатом решения задачи.
Это не я начал увязывать стресс с задачей. Разработчику В ЛЮБОМ СЛУЧАЕ придется рано или поздно работать в условиях стресса. Независимо от качества менеджмента. Он может начать работать медленее, может давать ЧУТЬ менее качественный код, но если из него начнет выходить говно, подобное приведенному выше - я бы с ним работать не захотел. Ни как менеджер ни как разработчик

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

> послушать такие рассуждения я вполне согласен. Над задачей
> же которую предлагается именно решить, часто не
> порассуждаешь. Как в той же задаче со стеклянными шарами.
Почему же. Можно к примеру для начала найти субоптимальное решение (для 20-ти бросков оно тривиально), а потом пытаться оптимизировать.

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

> Да, реальный случай, в крупной компании. Но там у них
> вообще много интересного было.
Хм. По моему не очень удачная задача. В приемлемые (для собеседования) сроки ее можно решить только если ты уже знаешь ответ. В конце концов они наберут людей, которые знают много паззлов, а не программистов.

> > Парадокс Монти-Холла наверное знаешь. Как раз по
> теорверу.
> Да, знаю. Хотя не понял при чем он здесь. До решения
Ты сказал, что отлично щелкаешь задачи по теорвер. Вот на этом парадоксе срезалось немало светил теорвера. Если бы не знал - я бы тебе его задал и посмотрел :-)

> > АВЛ - устаревшее говно. RB-деревья рулят :-)
> Может быть. Я не знаток деревьев.
Да пошутил я. Просто лично я смогу на интервью набросать хотя бы общую структуру RB-дерева, потому что вижу какая логика за ним стоит, а вот АВЛ я не понимаю и зубрить не хочу. По моему у Сейджвика читал, что АВЛ не гарантируют логарифмическое время операций для худшего случая, заглянул в вики - написано что гарантируют и при этом высота в среднем процентов на 20 меньше, чем у RB.

> Я вероятно не так немного выразился. Он не матрицу
> транспонировал, а вычислял новые координаты точек через
> умножение на матрицу поворота. Это конечно вырожденный
Ухты. Поточечно вычислял координату новой точки. Это да, сильно.

> клинический случай, но он показателен. Я не раз видел как
> программисты тратили несколько дней на "оптимизацию" и
"Преждевременная оптимизиация - корень всех бед" Энтони Хоар
Но как я уже сказал, это и не оптимизация вовсе, ибо человек не понял чего же он родил. Сложность примененного алгоритма не имеет ничего общего с его оптимальностью. Оптимальным в данном случае был precalculation (то есть хранение всех вариантов битмапа).

Кстати, уж какие упрощенные требования я ни предъявлял к соискателям (что поделаешь в нашем селе нанять бы хотя бы вменяемого, а не заниматься поиском бриллиантов), когда проводил собеседования, сложность основных операций над стандартными контейнерами я спрашивал ОБЯЗАТЕЛЬНО. Причем именно в O-нотации. Человек не знающий даже этого - вообще не программист. В реальных проектах такие товарищи склонны в лучшем случае к квадратичным решениям, но бывали случае экспоненциальных и даже факториальных.

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








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


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