Griboks

Нет, но пилят гос. контракты и обладают связями с коммерческим конторами по теме bigdata. Чтобы ворваться в эту сферу, подружиться с каким-нибудь доктором или зав. кафедрой очень поможет.

С другой стороны, если вас интересует теория, математика и прочее, то ищите в программе обучения: прикладная статистика, имитационное моделирование, дискретный и дифференциальный анализ.

Но в конечном итоге bigdata скоро лопнет и превратится в обычную сферу, как произошло например, с биткоином.

Вам ставят задачу - вы её обдумываете, читаете литературу, что-то проверяете и тестируете, проектируете, а потом уже пишете код, а потом снова тестируете и девопсите. Попутно затрагиваются другие интересные темы, которые вы тоже изучаете. Кто-то считает это рабочим временем, кто-то свободным (кроме писания кода).

Стандартная практика для джуна: вот тебе пару задач, которые надо сделать вчера, очень важные. А джун просто не в состоянии сказать (правильно сформулировать и донести до начальника): "У меня через 2 часа заканчивается рабочий день, завтра выходные, поэтому решу задачу через неделю, комиссия с проверкой подождёт." Это происходит, потому что джуны обычно чувствуют себя неопытными, неполноценными, что они не знают внутреннего устройства и процессов компании, что они кому-то должны. Отсюда возникают переработки, выгорания и заучивание этой "схемы", которую после повышения с чувством мести они реализуют на новых джунах.

Статические члены относятся к типу класса, а не его экземпляру. Это на один уровень выше в иерархии типов.

Такие члены нужны, чтобы задать свойства не конкретного экземпляру (объекту), а к целому типу (семейству объектов).

Например, мы хотим иметь несколько разных методов вычисления площади класса "гиперсфера" в зависимости от размерности пространства. Классический подход: передавать размерность в конструктор, а в методе GetSquare() каждый раз у каждого объекта проверять размерность и использовать соответствующую формулу. Однако, было бы проще задать размерность сразу для типа "гиперсфера", т. е статически. Тогда и в конструкторе меньше параметров, и каждый раз проверять не требуется, и лишняя память не тратится, и меньше кода писать, и новые объекты сразу создаются с нужной формулой. Иными словами, паттерн "фабрика".

Хотелось бы добавить, что стандартная реализация не стандартизирована и не рекомендуется к явному использованию.

Furthermore, .NET does not guarantee the default implementation of the GetHashCode method, and the value this method returns may differ between .NET implementations, such as different versions of .NET Framework and .NET Core, and platforms, such as 32-bit and 64-bit platforms. For these reasons, do not use the default implementation of this method as a unique object identifier for hashing purposes.

Вы точно прочитали документацию и правильно настроили колайдеры? Если нет, то вот вам и ответ. Если да, то, возможно, вам надо поменять метод проверки коллизий на постоянный.

Однозначно, читабельность. За скорость выполнения не беспокойтесь, C# сам её обеспечит на достойном уровне.

Если кратко: для вас смысла учить нет.

Если подробно...

1. Сложность/эффективность бывает разной. Обычно понимается как время выполнения или количество операций. Но также бывают и другие эффективности/сложности, например эффективность использования памяти.
2. Знание всей этой математики не даёт абсолютно никакой пользы при написании кода. Требуется оно только в двух случаях:
а) при проектировании (программным архитекторам) и только при условии жёстких ограничений (обычно слабого железа)
б) при оптимизации, когда вы просматриваете результат профилирования и видите узкое место в каком-то конкретном алгоритме