Открыть список
Как стать автором
Обновить

Моя история прохождения интервью в IB IT (Java разработчик, investment bank) в Лондоне с примерами типичных заданий

JavaПромышленное программированиеКарьера в IT-индустрииФинансы в ITИнтервью
Всего голосов 25: ↑20 и ↓5 +15
Просмотры19.2KКомментарии 86

Комментарии 86

Читать это все очень тяжело и неприятно.

спасибо за отзыв, согласен, статья требует дальнейшей редактуры. Просто очень большой обьем, постараюсь отредактировать
поезда отходят от платформы на восток и на запад с одинаковой частотой. Мужчина приходит на платформу и садится в первый поезд. Жена живет на востоке, любовница на западе — почему то так получается, что он чаще едет к жене — как так?..

Я правильно понимаю, что в этой задаче основной поинт в «востоке» и «западе»?

Не важно, просто есть два разных поезда (маршрута). Он садится на поезд, который пришел первый

а на станцию он с какой стороны заходит? или он по центру входит, между платформами (например туннель под путями как часто бывает на больших вокзалах) и ему что налево, что направо — одинаково по затрачиваемым усилиям?

Совесем неважно. Он приходит на станцию, которая, считайте, является материальной точкой. Садится на первый поезд и все.

Тогда, при прочих равных (стоимость проезда, время в пути, удобство посадки в поезд и тп), я пока что не вижу другого решения, кроме лежащего в плоскости эмоций и психики :)
Представьте, что интервалы между поездами в разные стороны такие: поезд на восток, 1 минута пауза, поезда на запад, 9 минут пауза, поезд на восток, 1 минута пауза и т.д. При этом интервал поездов в каждую сторону — 10 минут.
Возможное решение
Поезда уходят с разной частотой, но один, например, отправляется всегда незадолго до другого.
Опять же все сводится к психологии. Мне не трудно подождать 5 минут… или 10 минут, особенно если маршрут занимает 1..2..3 часа. Но я например не буду ждать следующего поезда 6 часов.
Мне кажется это из серии тех задач, где важен не ответ, а рассуждения.

Нет, нет, тут четкое математическое (и простое) решение, которое уже озвучили. Частота одинаковое, решение формальное — который первый пришел, на том и едет. Рассуждения всегда важны :-)

Вариант А:
Тот, который на восток, дольше набирает пассажиров, поэтому больше шансов попасть на него.

Вариант Б:
Та женщина, к которой чаще ездишь, та и жена.

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

А можете объяснить почему так получается что чаще к жене? Комментарии прочитал но что-то не понял.
я так понял, что если например поезда ходят каждый час и стоят на остановке 5 минут, но при этом поезд «на запад» уходит на пятой минуте часа, а «на восток» — на 59й минуте, то шанс попасть «не к жене» очень мал.
ИМХО, задача недоформулирована.
Мужчина приходит на промежуточную платформу, а поезда отходят с некоторой другой.

косвенно это подтверждает коммент ниже «Он садится на поезд, который пришел первый».

В этом случае да, это мат. задача, с решением.
Cогласно Java Language Specifications, chapter 10:

In the Java programming language, arrays are objects (§4.3.1), are dynamically created, and may be assigned to variables of type Object (§4.3.2). All methods of class Object may be invoked on an array.


     public static void main(String []args){
        Object[] arr = new Object[10];
        System.out.println(arr.length); // 10
        Object obj = new Object[10];
        System.out.println(obj.length); // ошибка
     }


Да собственно говоря все очень просто — в первом случае получаем массив объектов, во втором объект. Соответственно, можно обратиться по индексу, узнать длинну и так далее у o, а o2 это просто объект. Его можно привести к массиву, и тогда осуществить все операции что и для o:

     public static void main(String []args){
        Object[] arr = new Object[10];
        System.out.println(arr.length); // 10
        Object obj = new Object[10];
        System.out.println(((Object[])obj).length); // 10
     }

Ну ок, а в чем сложность, интерес, о чем тут можно вести разговор ?

Честно — пытался додуматься, ничего особого в голову не приходит, разве что можно порассуждать о equals и о том, что массив это по сути Object, а например int[] — нет
массив это по сути Object, а например int[] — нет

Эмм… Что?

Не знаю, почему так написал. Имел в виду, что массив объектов и массив примитивов слегка разное, хотя бы по возможности записать null и по инициализации.
ну null просто не входит в множество значений. В массив объектов нельзя записать примитив (я не про автобоксинг).
массив примитивов занимает столько же памяти как и массив оъектов (так ведь вроде?) (считаем что слово это 64 байта).
Собственно, в том примере отличается лишь типа «указателя»
Размер одинаковый, да:

    public static void printObjectSize(Object object) {
        System.out.println("Object type: " + object.getClass() +
                ", size: " + InstrumentationAgent.getObjectSize(object) + " bytes");
    }

    public static void main(String[] args) {
        Integer[] a = new Integer[10];
        int[] b = new int[10];

        printObjectSize(a);
        printObjectSize(b);
    }


Object type: class [Ljava.lang.Integer;, size: 56 bytes
Object type: class [I, size: 56 bytes
«не овтечают, если име не нужно, лоигка» поправьте пожалуйста.
поправил, еще опечатки — пишите в личные сообщения, с благодарносью поправлю
Спасибо, дельно! Про деньги забыли сказать, так чему равна цифра по glassdoor*1,5? ))

Ну это как температура по больнице, не знаю контекста любая цифра будет слишком абстрактна. Я бы сказал так, очень общо, программист в банке — 50к-150к в год. Но тут интересен вид распределения и вероятность попадание в определенный интервал этого распределения с течением времени, в этом плане агенты довольно хорошо могут прикинуть сколько примерно стоит тот или иной кандидат

Хм, и вы всерьез говорите, что условные 100к брутто-евро\фунтов в лондоне — это «лучше уровень жизни, чем в Мск» (где вы 200+ тысяч рублей в месяц получали небось)?
я не только серьезно говорю, я делаю сам такой выбор и вижу, его делают другие.
меня тут драйвит все вокруг, мне нравятся какие-то субьективные вещи — история, природа, музеи выставки, другая культура, профессиональное развитие, отношение к людям и качество сервиса, обьективные вещи — вроде лучшее качество сервиса, дорог, возможности путешествовать по всему миру. Можно вообще все это свести к субьективному мнению. я нехочу вступать в спор где лучше. Мне лучше тут, у меня возможность быть тут. вы хотите по-другому? я искренне надеюсь, что и у вас есть способ осуществить свое желание
Можете очень очень интересные задачи и очень очень хорошие деньги выразить в цифрах?

Очень интересные задачи, zero GC стриминг цен клиенту (то, что называется market making), order acceptance, написать market adapter, переписать существующие адаптеры, заменив их универсальным одним адаптером, разработка hft framework с возможностью проигрывать исторические данные для калибровки прайсинг и алго моделей при том, что с минимальными изменениями эта же модель будет использоваться и для реальной торговли (часто для калибровки используется матлаб или какие то сторонние симуляции), написание этих самых трейдинг моделей на пару с трейдерами, оптимизации производительности, микро анализ цен и аналитика происходящего на рынке в масштабах миллисекунд.
По деньгам, моя цель/мечта 150к-200к gbp в год.

Любопытно. Всегда думал, что скоростной трейдинг и анализ по умолчанию пишется на C, так как идёт борьба за каждую миллисекунду.

Как сейчас атмосфера внутри банков? Может так получиться, что в ближайшие пару лет совсем сложно им будет зарабатывать независимо от качества моделей. Если рынки снижаются по всему спектру, а скоро ещё и property может скорость набрать.

Большинство (ну ок, очень много) low latency пишется на джаве, покарйней мере большие системы, не сложно написать один компонент (джава плюсы), но вот это поддерживать и расширять, это большая задача. Программистов на джаве много, программировать проще. С плюсами сложней. Да, безусловно есть системы на плечах, есть и плисы, но джава превалирует. Посмотрите disruptor, aeron — это очень хорошие примеры на джаве. Их параметры производительности и лэтенси впечатляют.

а, атфмосфера отличная. в плане объемов, вроде все хорошо goo.gl/TfmkPP
по крайней мере, я в своем мирке этой проблемы не замечаю, не думаю, что в ближайшие пару лет будут какие-то потрясения, не вызванные глобильными кризисами (т.е. тренд хороший), для Лондона ключевой момент — брекзит, но опять так, как это затронит программистов. А так, шарахнуть может в любой момент, но хороший программист не пропадет (другой вопрос сколько он будет зарабатывать)
Так distuptor это только для матчинга заявок, как же всякие fpga feed handlers, алгоритмика вроде «попрайсить стрип опционов» и все такое?
дизраптор, это пример кода на джаве, который показывает высокую производительность и латенси. Используется для асинхронного взаимодествия и обмена информацией между тредами (producer consumer). FPGA — все слышали, никто не видел. Я думаю, что их применяют, но очень мало, на работу джава программиста это не влияет (в том смысле, что на разработчиков джава остается весь спектр задач и плисы их не вымещают). Что значит «feed handler» — плисы в маркет адаптерах, которые, например, парсят сообщения? На джаве это можно делать за 1-2 микрос (если мы говорим о текстовом протоколе, бинарный с фиксированными смещениями данных быстрей гораздо), это не является камнем преткновения, имхо. Алгоритмы вцелом, у банка задача быть в середине и полуачть прибыль за счет объема, не быть сильно медленным и не совершать больших ошибок. У спекулянтов задачи другие, я знаю о них по наслышке. Для сложных вычислений (опционы, поверхности волатильности, используются гриды, например — я лишь слышал об этом). Вообще говоря о банках я беру довольно малую часть — e trading, FX/equties. rates, commodities, не дай бог — asset managment — там по другому и мне сложно оценить насколько. Risk systems — еще более подругому, middle office, retail banking — вообще другая вселенная. Buy side — вселенная рядом, там nature of business другой, который всему придает другой оттенок
А что такое «гриды»?
Хмм, странно, я понимаю для анализа, но на стороне исполнения есть время чтобы данные куда-то перекидывать? Лейтенси же нереальный, даже если у вас инфинибэнд. Ну то есть, именно по этому fpga решения и существуют, если нужно такие вещи «в моменте» считать.
не знаю их специфики, не думаю что там нужно real time
На джаве это можно делать за 1-2 микрос

А на c++ (а тем более FPGA) еще быстрее. Но основная проблема не скорость, а GC.
gc free и lock free нам поможет. массивы, mutable objects.
ну опять таки — LMAX & disruptor — не является ли примером того, что на джаве может быть очень быстро?
Я далек от c++, я бы спросил про утечки памяти, сложность написания и поддержки програм
за сколько это можно сделать на плюсах? Т.е задача — получить из IO(TCP) FIX сообщение и распарсить.
Субмикросекунды, насколько я знаю. Но я в другой ветке писал, я сам как раз на java пишу.
Просто надо различать HFT и алгоритмическую торговлю (или даже не торговлю, а pricing/hedging). В HFT в основном c++, а у алго требования часто поменьше и java вполне хватает.
можете что-то рассказать про HFT? где именно это — prop дески в банках и очень немногочисленные хэджфонды, которые занимаются не только systematic trading?
какие задачи, какой обьем данных и какие требования к лэтенси. Что можно там сделать на плюсах, что нельзя на джаве, примеры (IO? паямть, кэши).
я так понимаю, вы тоже в Лондоне работаете? Где, если не секрет (можно в личку)
Особо ничего не могу, я только в теории знаком. Я как раз по java больше.
Но понятно, что сделать все можно что на c++, что на java. Насколько я понимаю, c++ предпочтительнее с точки зрения предсказуемости: в java GC и JIT все пор.
Понятно, что можно писать так, что GC не проблема и с прогревом JVM вопрос решаемый.
да, я бы сказал, что язык не камень преткновения, и там и там ест ьсвои нюансы и сложности. К тому же, джава стала такой быстрой не так давно, есть же системы которые начинались писаться 7-10 лет назад, например.

Работал в Citadel Securities, там все на C++, а непосредственно реактивный трейдинг на FPGA. Не уверен, что могу говорить точное время реакции, но это десятки/ок наносекунд. Разумеется, отвечает FPGA, а не CPU. Знаю, что XTX, например, кроме C++ используют http://luajit.org/dynasm.html HFT на Java тоже достаточно много, но я как-то миром Java не интересуюсь совершенно.

ух ты, это круто, очень круто. Не боитесь разглашать? десятки наносекунд это запредельно хоть для си хоть для чего еще. XTX — кстати, я присматривался к ним, кажется крутой компанией
не могу сейчас найти ссылку на источник, но пару лет назад один программист «из HFT» хвастался графиком сетевой активности, на котором пакет с ответом начинал уже «уходить» с исходящей сетевой карты еще до того, как весь пакет с информацией доходил до принимающей. Да, это FPGA, но кодогенерацию (т.е. правила как и что торговать) для него они делали на языке высокого уровня (ЕМНИП на хаскеле, но уже точно не помню, тут могу и соврать, но точно не С\С++).
пакет с ответом начинал уже «уходить» с исходящей сетевой карты еще до того, как весь пакет с информацией доходил до принимающей

т.е. он начинает отвечать, не дослушав вопрос :-)?
нисколько не хочу подвергать сомнению, я бы внимательно посмотрел как графики строятся
к сожалению это было давно, сейчас погуглил по жжшкам, которые в то время читал (1, 2, 3, 4, 5, 6), но сходу ничего не нашлось, увы.

т.е. он начинает отвечать, не дослушав вопрос :-)?
я могу только предположить, что там шел заголовок пакета (это уже для тела нужно дослушать, а голову можно заранее пускать). И понятно, что стандартные драйвера\железо как минимум — дочитывают пакет (а могут еще и в буфере хранить перед передачей в код).
надо посмотреть что делает Solarflare.
Мне на ум пришел ткой сценарий, когда можно недочитвыват,
например у нас есть поток цен и мы для каждой цены выставляем ордер на бирже, а по приходу новый сначала отменяем предудущий и шлем новый (и на бирже не поддерживается cancel replace), тогда это имеет значение.
Спасибо за ссылки

Может, Ocaml и JaneStreet. Хотя не знаю, используют ли они FPGA. А так пакет (точнее, нотификация о пакете) может доходить до CPU действительно медленнее, чем FPGA пошлет на него ответ.

может, еще есть какая-то информация про хэдэфонды? ну там, статьи, публикации, презентации, которые можете порекомендовать? Мне это очень интересно, учитывая что там нет джавы, врядли я когда то это увижу воочию
Почему нет, полно java. Разве что конкрето на таких позициях нет.

Prop десков в крупных банках имхо не осталось (спасибо Volcker rule), только хежд фонды. Даже в относительно либеральном cash fx приходится натягивать pre-hedging на глобус чтобы как-то оправдать сам факт наличия ненулевой позиции (если банк большой и хранит кучу пенсий европейских старушек).


Но я бы на месте автора не особо заморачивался с ультра-быстрым HFT. Его тучные годы давно прошли, про FPGA и microwave все в целом знают, и сейчас нужно искать баланс между гибкостью и скоростью. Не факт что этот баланс лежит в области наносекунд. Хотя чисто технически наносекунды конечно интересны и впечатляющи.

И вообще крутые посоны используют ASIC и смеются над твоим FPGA.
Вот вам еще задачка на личную тематику. В одной стране ипотека дается под 2% и инфляция 2%(цены(на квартиру тоже) и зарплаты растут на 2% в год). В другой стране ипотека дается под 15% и инфляция 15%. Где и когда выгодно брать квартиру?

PS это не про РФ, так как тут цены на квартиры падают вроде.
оговорюсь сразу — это не только имхо, это просто мысли вслух и я типа думаю, как вам привести контр-аргументы.
а как дела со скоростью накопления первоначального взноса, его размером? Соотношением зарплаты professionals ( а можно предположить, что в стране с худщей экономикой труд будет цениться меньше, а связи больше — это я так тонко про коррупцию- ?) к стоимости жилья? Я претендую только на работу специалиста, а не ресурсного менеджера или человека, использующего административный ресурс (это не оценочное суждение, а просто моя ситуация)
Большая инфляция говорит о нестабильности, ипотека это комитмент на долгие годы, стабильная ситуация делает рынок надежным, предсказуемым и, как следствие, более эффективным, значит, ставки будут ниже, маржа банков меньше, как следствие — рынок недвижимости больше и также эффективным. Хотя, как менялись ценю в Лондоне до брекзита, это отдельная история — рынок грелся и ипотечные кризисы в США, кстати, докозательство неэффективности системы (это я сейчас против себя говорю :-) ) (и в США сейчас кстати ставки, по-моему, не 2 процента). При нестабильности банки будут закладывать бОльшие риски, которые лягут на плечи потребителя, т.е. кредит будет дороже. И если все будет хорошо, то вы больше за него переплатите, если все накроется — вообще потеряете квартиру.

А вы про какую страну, кстати?
при заданном объеме найти цилиндр максимальной площади

Странная задача. Точно не ошиблись в формулировке? При фиксированном объёме, если высота цилиндра будет стремиться к нулю, его площадь очевидно будет стремиться к бесконечности.
ну, это не самая сложная задача. Но я поправил на
«при заданном объеме найти цилиндр максимальной/минимальной площади»
чтобы закрыть тему. Кстати, простые задачки в начале интервью, на мой взгляд, очень помогают разогреться и включить мозги, ну и опять таки — sense of achievement.
Статья хорошая, финансы самому интересны, но, по-моему, не раскрыты как раз самые важные вопросы:
  • как вообще попасть в Лондон
  • как получить первую работу там в банке
  • есть ли шансы (и какие) устроиться из России, везут ли вообще людей из-за границы
и тд

Я бы задался вопросом "зачем" в первую очередь. UK — не лучшая страна для жизни, а зарплаты программистов не слишком высокие тут, если сравнивать с США, а в относительном плане, так и с Москвой. Финансы — это достаточно специфическая и достаточно неприятная область для программиста (как минимум в плане work-to-life баланса).

ну я уже задался вопросом «зачем». после этого остались вопросы, которые я написал выше.
выбор стран, зарплат, США — ничего не скажу, все индивидуально и слишком много других факторов. В плане баланса — нууу, по моему все нормально. Пришел в 9 ушел в 18. до дома комфортные 30 минут (или 60 если жить в доме загородом с семьей). Нормальный обед, можно сходить в спорт зал.
Центрального отопления нет, батареи все электрические, домовладелец экономит на электричестве и не часто их включает в зимний/весенний период. В доме холодно, спите под двумя одеялами. Кран разделён на отдельную горячую и холодную воду (в 21 веке до сих пор), горячая вода дорогая так как расходуется электричество, ванную, как в РФ, уже не попринимаешь пару раз в неделю.

Мои воспоминания пересекаются с вашей реальностью быта?
2 раздельных крана это скорее редкость.
Для какого города? Если Москва не Россия, то Лондон видимо не Британия, а в «ней», Британии, кран со смесителем для меня был чудом (Манчестер, Ливерпуль, Эдинбург, Йорк, ...)
Возможно в туристических зонах дело получше ибо европейцам это дикость.

Есть и газовое отопление, оно дешевле. Но да, если электрическое, то зимой 150 фунтов в месяц

«Подготовку к интервью я рассматривать совсем не буду. Считаем, что это пройденный этап, необходимые знания есть, и есть приглашения на интервью.»
Работа в банках это большая тема не на одну статью (мне кажется, это будет очень сложно сделать, слишком уж неоднородно и слишком уж субьективно, так, в общих чертах пользы будет много). Мой итог — интересно и хорошо, я считаю мне сильно повезло, что я попал туда.
Как попасть в Лондон, ну тоже, как вы представляете ответ на этот вопрос?
ПОстараюсь коротко, про иммиграцию вообще.
Главные вопросы «зачем и ради чего», предположим отвечены. Есть программы иммиграции (blue card, в Британии раньше была Teir1 виза), компании перевозят сотрудников по inter company transfer (соот-но ищите компанию в вашем городе, у которой есть офис в Лондоне), ну и просто компании из Лондона нанимают сотрудников из-за рубежа, делают визу и т.д. — ничего не могу сказать насколько это сложно, знаю, что случаи есть и они не то, что перевезли какую-то супер звезду. Но чем больше опыта работы и выше квалификация, тем проше (ну тоже с неким допущением, чем больше опыт, тем меньше работы, соответствующей ваше квалификации). Наверное оптимально будет mid/senior developer.
Так что шансы есть всегда :-)

Можно еще через учебу. Но если вдруг будете подаваться на PhD, то постарайтесь сделать это по Tier 2, а не по Tier 4 визе. А то мы сделали такую ошибку, и теперь нужно ждать на три года больше, чтобы податься на ПМЖ...

При ПМЖ гражданство теряется?

При ПМЖ? В смысле, один из вариантов, живёте 5 лет на внж, потом год на ПМЖ и постоянно юк гражданство. Если ваше предыдущее гражданство позвонят иметь два, то ничего не теряется :-)

есть 2 текста ( каждый по 1GB), по одному у каждого пользователя. Пользователи могут обменяться только <1000 байтами, как понять одинаковые ли у них тексты в 99% случаем (важно — не чтобы это работало на 99% текстов, а именно в 99% случаев сравнения лубых двух текстов). Тут просто поговорить, т.к. полная формулировака задачи — сколько надо бит информации, чтобы вероятность успеха была 1-epsilon — это уже большая задача не для интервью (и не только для программиста, но и для математика).


Я может немного не понял, но как предполагается достичь условных 99%, если передать можно всего 1e-4% информации? И вообще, по каким ключевым словам подобные задачки гуглить?
А как по-вашему проверяется — тот ли файл был скачан по сети\ с торрентов?
гуглите контрольные суммы, проверка целостности, хеши файлов и прочие подписи: CRC, MD5, Merkle Trees и т.д.

Ааа, контрольные суммы! Точно, что-то с утра туго соображается, даже не подумал об этом. Спасибо!

Контрольная сумма работать не будет. Есть ненулевая вероятность что мы двух текстов она будет одна и та же. Нужен способ, который бы работал в 99 процентах случаев для ВСЕХ текстов

В смысле? Конечно, будет ненулевая вероятность. В этом вроде и вопрос был — гарантировать вероятность коллизии на двух текстах не более 1%? Или я опять что-то не так понял?

возможно, задание не совсем точно сформулировано. Но для любой пары, включая ту, для которой коллизия произошла), должна быть 99 вероятность, что с одного раза можно установить идентичность (это отчасти поздсказка, что хотел услышать интервьюер).
т.е. не с вероятностью 99 для любой пары, а для лбой пары с 99 вероятностью (не уверен, что это корректной определение, но суть такая, как я поисал выше).
мне кажется, или в этой формулировке «99 вероятность, что с одного раза можно установить идентичность» — то есть «в 1% мы скажем что тексты разные, хотя они были одинаковыми», оно звучит даже хуже, чем «с хешами»?
При этом я не берусь утверждать, что если взять например (длину текста+Н байт конца и начала+один хеш от всего текста+другой хеш корня дерева меркла), то не найдется двух разных текстов, на которые эти признаки скажут «тексты одинаковые». Но вероятность такого события мне видится весьма малой.
ИМХО, в такой задаче можно разве что рассуждать об оценках снижения трудоемкости (чтобы меньше считать) или уменьшения количества байт для обмена…

PS: ведь в простейшем случае — хватает просто длины файлов, чтобы свести только к ложноположительным случаям (т.е. когда при одинаковом размере у них таки разное содержимое).
ок, моя идея, по крайней мере. При каждом сравнении мы добавляем псевдо рандонмую информацию (одну и ту же для обоих тестов). Тогда при выполнении определенного (я думаю очень маленького, типа 2,3,4,5) количества сравнений с добавленными разными псеворандомными значениями мы получим одинаковые значение для одинаковых текстов (всегда) и разные для разных тектосв (в 99 случаев, т.к. может так получится что хэш совпал несколько раз). как вам идея? Если сочтете ее стоящей, то как надо изменить исходное задание, чтобы было сразу понятно?

Ну вы про хэш с солью говорите, правильно? Но зачем он здесь при данных условиях?
В терминах "2 текста, 1% ошибок, 1000 байт на хэш" вам простого md5/sha хэша будет достаточно, чтобы не 1 процент ошибок иметь, а 2^-160 (sha — 160 бит на хэш) вероятности или около того.
Надо лучше — берите две разные (независимые) хэш-функции, вероятности перемножатся.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.