План запроса меняется автоматически в зависимости от статистики, то есть на разном объеме данных/разном содержимом может быть по разному.
Совершенно верно. Чтобы спроектировать структуру данных в общем случае надо представлять примерную ожидаемую статистику и как работает оптимизатор
Примерно столько времени понадобилось одному из джунов (не самому таланливому в программировании), которого я натаскивал.
Вопрос, помогло бы ему если бы он уже знал как рассуждать о производительности быстрее и лучше оптимизировать или нет. Мне кажется, в принципе в массах культура формального рассуждения весьма хреноватая и многим было бы полезно научиться не только интуитивно научиться каким-то приемам но и знать почему так и какие ограничения и т.д. И мочь передать это днание другим
Просто для меня это нерелевантно. Я тоже не собеседую ДИТ и топ-менеджеров. Интересно просто. Например, если предупреждать о стресс-тесте не перестанет ли он быть стресс тестом?
Оптимизировать нужно в связке в реальной среде. Куда больше реальной пользы приносит правильно написанный запрос к СУБД, чем правильно развернутый цикл.
В субд те же индексы (хеши и двоичные деревья) и hash и merge joins и nested loops — т.е. надо понимать как все работает и сообразить какая o(f(n)) там будет.
Возможно вы удже походили по этим ссылкам и составили представление о том насколько часто и в каких компаниях такое проводится? По вашей рекомендации статьи без указания конкретики. Вы сами с таким встречались?
Но скажем ради проверки стрессоустойчивости вам плеснут горячий кофе на костюм. Вряд ли рядовому программисту будут проводить такой тест, но вот ДИТ уже могут.
Т.е. если получил 4 — значит предмета не понял, недоработал, упустил время и шанс. И ни когда не нагонишь, потому что статистически маловероятно, что ты будешь получать второе образование по тому-же профилю или повторно посещать тот-же курс.
Это подразумевает, что оцениваетя именно понимание, а не знание кучи фактов, и информацию можно получить только прослушав какой-то курс в университете.
Это скорее про обозначения, чем про определения. Но это часть правды. Если бы отец сказал это Фейнману по-китайски, то он бы не понял его. Потому, что Фейнман не знал бы обозначений.
Он будет знать, что ему будут просто задавать вопросы, на которые не надо проявлять чудеса интеллекта, а надо просто отвечать, как есть.
Да, мне кажется, что на тестировании что на собеседовании так и надо. Вернее для меня эти понятия четко не различаются. Всегда оцениваешь не только, что но и как кандидат говорит — т.е. одновременно и беседа и эксперимент.
Грубо говоря, собеседование направлено на взаимопонимание, а тестирование — вещь односторонняя.
Кандидат может вполне по уровню задач тоже оценивать работодателя. Это вещь двухсторонняя всегда. Условно это рынок, есть покупатель, есть продавец. Бывают рынки покупателей, бывают рынки продавцов. И, по-моему, для хороших специалистов в нашей индустрии, скорее, второе.
В тайпскрипт еще есть ограничение глубины проверки (т.е. проверяется вниз на N уровней) иначе она может занять бесконечное время для рекурсивных структур данных или типа того. Поэтому там дизайн-там чекинг не гарантирует соответсвие типов в рантайме. Интересно, как в других языках.
Я бы в уме поставил + такому человеку за технические навыки, и — за конструктивность и желание сотрудничества (после попытки объяснить явно что от него в целом требуется на собеседовании типа «напишите копирование файлов без учета всех этих тонкостей, а потом расскажите про компромиссы на которые пришлось пойти для скорости написания»)
Совершенно верно. Чтобы спроектировать структуру данных в общем случае надо представлять примерную ожидаемую статистику и как работает оптимизатор
Вопрос, помогло бы ему если бы он уже знал как рассуждать о производительности быстрее и лучше оптимизировать или нет. Мне кажется, в принципе в массах культура формального рассуждения весьма хреноватая и многим было бы полезно научиться не только интуитивно научиться каким-то приемам но и знать почему так и какие ограничения и т.д. И мочь передать это днание другим
Чтобы эффективно общаться с другими.
В субд те же индексы (хеши и двоичные деревья) и hash и merge joins и nested loops — т.е. надо понимать как все работает и сообразить какая o(f(n)) там будет.
Насчет минуса не знаю, а дефис и длинное тире автоматически вставляется многим софтом. Например в том самом сообщении, на которое я отвечаю ;)
Кто когда и где такое делал?
Дам ему проверить. Почему надо на это оскорбляться?
Это подразумевает, что оцениваетя именно понимание, а не знание кучи фактов, и информацию можно получить только прослушав какой-то курс в университете.
Очевидно, функция которая сама себя вызывает, т.е. рекурсивная ;). (на самом деле, наверное, module pattern)
Это скорее про обозначения, чем про определения. Но это часть правды. Если бы отец сказал это Фейнману по-китайски, то он бы не понял его. Потому, что Фейнман не знал бы обозначений.
А почему чушь? Семантически же это разные случаи?
Да, мне кажется, что на тестировании что на собеседовании так и надо. Вернее для меня эти понятия четко не различаются. Всегда оцениваешь не только, что но и как кандидат говорит — т.е. одновременно и беседа и эксперимент.
Кандидат может вполне по уровню задач тоже оценивать работодателя. Это вещь двухсторонняя всегда. Условно это рынок, есть покупатель, есть продавец. Бывают рынки покупателей, бывают рынки продавцов. И, по-моему, для хороших специалистов в нашей индустрии, скорее, второе.
А еще доктор Менгеле делал неприятные эксперименты. Да. Получается, оскорбительно/неприятно не то, что это эксперимент сам по себе, а что-то другое?
Кто-то делает так на собеседованиях программистов? Ну тогда мы это вместе осудим. Но какое это имеет отношение к тексту?