При бурении скважин установлено, что температура Земли с глубиной повышается, на глубине 10 км она достигает почти 200°. Это объясняется мощным тепловым потоком, идущим из горячих недр Земли.
Если я их Вам пришлю, то вопрос будет исчерпан, а мне хотелось бы сейчас понять какими утилитами не стоит пользоваться для исправления ошибок. А какая версия Word? Только что проверил у себя, всё отлично определилось. Не воспринимайте это как обвинения, это был не более чем совет проверять грамматику, а сейчас мне интересно вычеркнуть для себя ненадёжный в этом плане софт.
Нет, проблема, конечно, не в ё. А в тся/ться и опечатках, не думаю что какая-то утилита могла бы пропустить такое. А чем проверяли, как называются утилиты?
Я бы подумал, что интервьюер заливает стандартными хвалебными фразами о своей компании. Потому что он не знает меня и не догадывается что мне будет интересно от команды/компании. Также это ещё не факт что эту работу получу именно я, а значит на последний вопрос — чистой воды лесть и враки. В общем я бы ответил в таком же ключе, что я целеустремлённый спортсмен-экстремал, лидер-профи в своём деле обучаемый-усидчивый и вообще золотая жила для компании, и что компания просто супер потому что (все пункты из ответа компании на вопрос 2). В общем чисто исходя из корпоративной этики, залил бы стандартными ответами, которые просто приятно слышать, и которые с действительностью часто пересекаются слабо.
Я тоже их задавал, собственно поэтому и написал, не совсем понимаю минусы, если все их задают. Более того, из полученных ответов понятно, чего от тебя ждёт в качестве ответов интервьюер.
Хах, а я бы вот задал встречные вопросы:
— «Чем компания любит заниматься?»
— «Какие качества команды/компании будут полезны мне?»
— «Почему вы хотите взять меня на работу?»
Кстати, «hardly» переводится как «едва ли», а никак не «более тяжко». Ох, был у меня инцидент с работодателем, которому я говорил что я такой молодец и я «hardly working on it», а он нервничал и пытался добиться чем же я тогда занимался! Прояснил ситуацию сторонний наблюдатель, ржали тогда все вместе, прокатило как для не нейтив спикера, но стыыыдно было. Так что не наступай на мои грабли, bro! ;)
Мне кажется, Вы плохо понимаете как работает оптимизатор базы данных, индексы и B-деревья. Никаких OR в каждой строке не будет, более того, разнося по разным полям настройки, Вы будете использовать логическое умножение, что будет только сужать выборку. Бесспорно, выборка по индексу конкретного значения будет быстрой операцией, но Вы не учитываете что это не цель. Последующая обработка результата, его сортировка и ограничения накладываемые этим подходом сведут на нет изначальное преимущество, при куда менее прозрачной модели приложения. Более того, поиск одного конкретного значения это частный случай, на практике построенные запросы будут куда сложнее.
А в чём будет бонус подхода, по сравнению с отдельными полями для региона, опубликованности и прочего? Конечно, если отбросить варианты что у команды разработчиков фобия, связанная с количеством полей в таблице. И, конечно, Вы должны понимать, что при инсерте/апдейте/делите одной настройки из набора, будет запущена перестройка индекса, который в случае со слепленными настройками в одну битовую маску, будет гораздо жёстче чем по отдельному полю.
Вы разработчик онлайн-игрушки с миллионом пользователей. Задача вывести 50 пользователей на страницу, конечно, заблокированных не нужно выводить, и скрытых тоже, а ещё отсортировать просят по уровню доступа. Все эти настройки записаны в виде одной битовой маски в поле flags (судя по коду оно не BINARY и фильтрация происходит в PHP). Это залёт?
Правильно я понимаю, что это — «прощайте индексы»? Если у вас будет 1 000 000 сущностей, содержащих параметр-флаг, то для выборки по этому флагу Вы устроите полный проход таблицы?
— «Чем компания любит заниматься?»
— «Какие качества команды/компании будут полезны мне?»
— «Почему вы хотите взять меня на работу?»