Комментарии 13
Почему такое не спрашивают на собесах? А то достали уже:
А что выведет такая цепочка промисов?
И там происходит какая-то дичь с массивом из цифр, true/false, null и undefined
Есть пара не очень понятных вопросов.
Осторожно спойлер
Вопрос с паттерном стратегия. Как раз была такая ситуация на реальном проекте. Наличие стратегии не является достаточным условием. Вызовы во внешние системы идут не один к одному, а один наш вызов может раскладыватся на несколько внешних вызовов. И в разных внешних системах - это будет разный набор. Что тоже есть адаптер. Так вот, в этой ситуации я лучше забуду применить полноценную стратегию, чем адаптер. Правильный ответ "адаптер + стратегия". И адаптер тут важнее.
И 10-ый вопрос. Там как раз таки сначала будет хэш таблица, а вот в ней ключом будет ид клиента (номер паспорта), а вот значением будет битовая карта. Сначала мы ищем сам ключ, и только потом находим соответствующую битовую карту. Поэтому правильный ответ "хеш таблица + битовая карта". И хеш таблица тут важнее.
И есть вопрос слабо относящийся к программистам (для которых составлена большая часть вопросов). Это вопрос про ИИ. Дата сатанизм имеет свою узкую специфику.
>> вопрос про ИИ
по предложеным ответам вполне можно логически выбрать верный.
соглашусь про хэш таблицу. а паттерны использую на практике - названий и не знаю...
И 10-ый вопрос. Там как раз таки сначала будет хэш таблица, а вот в ней ключом будет ид клиента (номер паспорта), а вот значением будет битовая карта. Сначала мы ищем сам ключ, и только потом находим соответствующую битовую карту.
А зачем нужна хэш-таблица, если идентификатор числовой и его длина ограничена (номер паспорта)? Можно сразу искать в битовой карте. Аналогично можно сразу искать в хэш-таблице, но чуть медленнее и (предположительно) памяти больше.
Ну, на практике-то, номер паспорта может оказаться строкой, а не числом, но по условию - число.
Спасибо за разъяснения. Если честно, вводит в ступор именно ответ. На практике чаще всего на уровне идентификатора, который используется на входе, используется именно строка, а не целое число. Эту строку все равно придется валидировать, а потом уже проверять по битмапу. Так что конечно, я бы ещё протестировал , какой подход в итоге будет в реальной жизни быстрее работать.
Хм, даже если это число (номер паспорта или ИНН), то битмэп будет очень большой и почти полностью пустой и не даст никакой информации, кроме "такой у нас уже есть". Разумный хэш будет компактнее и давать почти ту же линейную скорость поиска, так как внутри там тот же самый массив бакетов, достаточно большой.
Если нужно еще быстрее, то можно прикрутить фильтр блюма.
Можно подробней как бы это работало?
Смущают следующие моменты:
Это что один большой бинарник? Насколько удобно его потом расширять? Появятся дополнительные флаги или внезапно длина ключа станет переменной длины
Этот бинарник не появится волшебным образом в памяти. Этот срез данных мы будем где-то хранить. Как минимум реляционка с индексами. А скорее всего no-sql ключ-значение.
Это что один большой бинарник? Насколько удобно его потом расширять? Появятся дополнительные флаги или внезапно длина ключа станет переменной длины
Ну как большой... В номере паспорта 10 цифр, это 10млрд. паспортов, или 10млрд.бит = 1.25ГБ. Про расширение ничего не сказано. Но такой небольшой объём недолго конвертировать во что угодно, если вдруг потребуется.
Этот бинарник не появится волшебным образом в памяти. Этот срез данных мы будем где-то хранить. Как минимум реляционка с индексами. А скорее всего no-sql ключ-значение.
Сомневаюсь, что это энтерпрайзно, но что-то вроде файлового io здесь подходит. Либо грузить из файла постранично, либо использовать отображение в память... Осталось только транзакции прикрутить. С другой стороны, те страницы-куски битмапа можно в любой БД хранить. Это если специального "bitmap" индекса в БД нет. В postgresql есть, но мне не приходилось пользоваться.
В реальном финтехе, конечно, там не паттерн стратегия, а несколько стратегий и проксей, связанных через workflow. Иногда можно обойтись списком из нескольких стратегий, но это неудобно.
тамада интересный, и конкурсы у него веселые.
если бы можно было поставить плюсик, я бы поставил.
Интересный тест, как джуну в финтехе было интересно подумать и записать для себя пару вещей, в которых на будущее стоит разобраться.
Я что-то не понял, с самого начала) service mash ->istii, берем ingress и пишем там правила роутинга к конечным app, чем это хуже подхода с gateway?
Миру нужен герой: финтех-тест для суперспециалистов