Мы открываем набор в отряд героев финтеха. Тебе будут заданы вопросы из самых разных банковских сетей, ответы на которые мы ищем в нашей повседневной работе. Докажи, что ты способен выйти за рамки узкой специализации, что ты универсальный гений и человек Ренессанса, готовый в одиночку держать IT-отдел финтех-компании на плаву.
Поехали!
Мы открываем набор в отряд героев финтеха. Тебе будут заданы вопросы из самых разных банковских сетей, ответы на которые мы ищем в нашей повседневной работе. Докажи, что ты способен выйти за рамки узкой специализации, что ты универсальный гений и человек Ренессанса, готовый в одиночку держать IT-отдел финтех-компании на плаву.
Поехали!
Комментарии (13)
onets
03.09.2021 21:56+4Есть пара не очень понятных вопросов.
Осторожно спойлер
Вопрос с паттерном стратегия. Как раз была такая ситуация на реальном проекте. Наличие стратегии не является достаточным условием. Вызовы во внешние системы идут не один к одному, а один наш вызов может раскладыватся на несколько внешних вызовов. И в разных внешних системах - это будет разный набор. Что тоже есть адаптер. Так вот, в этой ситуации я лучше забуду применить полноценную стратегию, чем адаптер. Правильный ответ "адаптер + стратегия". И адаптер тут важнее.
И 10-ый вопрос. Там как раз таки сначала будет хэш таблица, а вот в ней ключом будет ид клиента (номер паспорта), а вот значением будет битовая карта. Сначала мы ищем сам ключ, и только потом находим соответствующую битовую карту. Поэтому правильный ответ "хеш таблица + битовая карта". И хеш таблица тут важнее.
И есть вопрос слабо относящийся к программистам (для которых составлена большая часть вопросов). Это вопрос про ИИ. Дата сатанизм имеет свою узкую специфику.
amarkevich
04.09.2021 09:13>> вопрос про ИИ
по предложеным ответам вполне можно логически выбрать верный.
соглашусь про хэш таблицу. а паттерны использую на практике - названий и не знаю...
Akon32
10.09.2021 18:54И 10-ый вопрос. Там как раз таки сначала будет хэш таблица, а вот в ней ключом будет ид клиента (номер паспорта), а вот значением будет битовая карта. Сначала мы ищем сам ключ, и только потом находим соответствующую битовую карту.
А зачем нужна хэш-таблица, если идентификатор числовой и его длина ограничена (номер паспорта)? Можно сразу искать в битовой карте. Аналогично можно сразу искать в хэш-таблице, но чуть медленнее и (предположительно) памяти больше.
Ну, на практике-то, номер паспорта может оказаться строкой, а не числом, но по условию - число.
Senshi26
16.09.2021 13:29Спасибо за разъяснения. Если честно, вводит в ступор именно ответ. На практике чаще всего на уровне идентификатора, который используется на входе, используется именно строка, а не целое число. Эту строку все равно придется валидировать, а потом уже проверять по битмапу. Так что конечно, я бы ещё протестировал , какой подход в итоге будет в реальной жизни быстрее работать.
dph
24.09.2021 05:46Хм, даже если это число (номер паспорта или ИНН), то битмэп будет очень большой и почти полностью пустой и не даст никакой информации, кроме "такой у нас уже есть". Разумный хэш будет компактнее и давать почти ту же линейную скорость поиска, так как внутри там тот же самый массив бакетов, достаточно большой.
Если нужно еще быстрее, то можно прикрутить фильтр блюма.
onets
24.09.2021 07:00Можно подробней как бы это работало?
Смущают следующие моменты:
Это что один большой бинарник? Насколько удобно его потом расширять? Появятся дополнительные флаги или внезапно длина ключа станет переменной длины
Этот бинарник не появится волшебным образом в памяти. Этот срез данных мы будем где-то хранить. Как минимум реляционка с индексами. А скорее всего no-sql ключ-значение.
Akon32
24.09.2021 07:35Это что один большой бинарник? Насколько удобно его потом расширять? Появятся дополнительные флаги или внезапно длина ключа станет переменной длины
Ну как большой... В номере паспорта 10 цифр, это 10млрд. паспортов, или 10млрд.бит = 1.25ГБ. Про расширение ничего не сказано. Но такой небольшой объём недолго конвертировать во что угодно, если вдруг потребуется.
Этот бинарник не появится волшебным образом в памяти. Этот срез данных мы будем где-то хранить. Как минимум реляционка с индексами. А скорее всего no-sql ключ-значение.
Сомневаюсь, что это энтерпрайзно, но что-то вроде файлового io здесь подходит. Либо грузить из файла постранично, либо использовать отображение в память... Осталось только транзакции прикрутить. С другой стороны, те страницы-куски битмапа можно в любой БД хранить. Это если специального "bitmap" индекса в БД нет. В postgresql есть, но мне не приходилось пользоваться.
dph
24.09.2021 05:48В реальном финтехе, конечно, там не паттерн стратегия, а несколько стратегий и проксей, связанных через workflow. Иногда можно обойтись списком из нескольких стратегий, но это неудобно.
dd84ai
07.09.2021 17:51+3тамада интересный, и конкурсы у него веселые.
если бы можно было поставить плюсик, я бы поставил.
fractum
07.09.2021 17:51Интересный тест, как джуну в финтехе было интересно подумать и записать для себя пару вещей, в которых на будущее стоит разобраться.
blindmen
14.09.2021 18:52Я что-то не понял, с самого начала) service mash ->istii, берем ingress и пишем там правила роутинга к конечным app, чем это хуже подхода с gateway?
exibite777
23.09.2021 17:13+1Спасибо. Отличный тест. Как раз в финтехе работаю. Немного гуглил, но мне как аналитику допустимо. Пару интересных ссылок сохранил. Автор теста конечно угарный человек, с фантазией, особенно запомнилось про шаблон проектирования «SQL инъекция». Хохотался от души
hello_my_name_is_dany
Почему такое не спрашивают на собесах? А то достали уже:
И там происходит какая-то дичь с массивом из цифр, true/false, null и undefined