Кадры в брендовых компаниях

Все-таки интересно, откуда такие компании как Гугл берут людей? Ведь их продукт - это их технологии, а значит нельзя просто найти людей с опытом работы с этими технологиями.
Думаю, политика при наборе кадров примерно следующая.
1. Безоговорочно покупаются люди с именем, уже зарекомендовавшие себя. Частенько эти люди покупаются вместе с их компаниями. Эти люди двигают идеи и мысли, занимаются исследованиями, строят концепты, ездят по конференциям и пиарятся.
2. Набирается и обучается свеженькая молодежь. Это инвестиция в будущее, залог успеха и востребованности технологии.
3. Ну и наконец, помимо крутых интересных инноваций, есть и куча рутинной работы. Ее, я полагаю, выполняют обычные середнячковые программисты с рынка труда. То есть что в гугле, что в любой другой компании эта работа приблизительно одинаковая, и никакой рокет сайенс тут не нужен. Тем не менее, компания пытается поддерживать имидж высокотехнологичной и требует от соискателей решения непростых задач. Хотя со временем, конечно, средний уровень понижается, как и в любой крупной организации.

C# decimal

Нарвался на проблему с точностью представления чисел с плавающей точкой. Вот уж не думал, что это может случиться.
Сначала для представления денежных величин начал использовать decimal. Все бы хорошо, но тут я уперся в требования по времени работы программы. Аналитические вычисления занимали по три дня. Прошелся профайлером, обнаружил, что операции работы с decimal, даже такие простые, как, скажем, инкремент на 1, занимают в общей сложности около 15% времени. Ужаснулся. Я понимаю, что decimal реализован программно и не поддерживается инструкциями процессора, но чтобы настолько медленно, я не ожидал! Попробовал пописать простые тесты, делающие в цикле много примитивных арифметических операций с разными типами - decimal оказался медленнее в десятки раз!
Ну и ладно, подумал я, заменю все на double. Это же не расчет зарплаты, в конце-то концов, а аналитические вычисления, порядка точности должно хватить. Но после очень приблизительных прикидок получилось, что погрешность самого математического метода, да погрешность округлений, накопленная за несколько тысяч операций, в денежной интерпретации дает не такие уж и малые величины.

Блин, что делать? Судя по всему, такие проблемы тривиально не решаются.. То есть надо менять математику вычислений. А это явно за рамками разрабатываемого проекта.