Comments 5
Насколько мне известно у таких разрабов одни из самых высоких ЗП.
В основе систем для финансовой сферы лежат базы данных, поэтому разработчикам понадобятся глубокие знания SQL. Знания простых операторов выбора будет недостаточно — довольно часто в ходе работы придется иметь дело с созданием процедур хранения, разбираться с индексами, и различными типами блокировок.
Да, простых базовых знаний, как для веба — маловато будет.
На Хабре есть серия статей, что банкам приходится держать сервера специально на процессорах архитектуры RISC, чтобы справляться с нагрузками.
Добавлю несколько капель дёгтя:
Итог: я не хочу никого отговорить идти в финансы, но таки иметь в уме эти минусы полезно, если вы привыкли к самым последним «фишкам» — вполне вероятно, что придется откатываться лет так на 3-5 в области некоторых софтовых технологий.
- если железо как правило, довольно современно, то вот с софтовыми технологиями часто бывает просто беда из-за «compliance» и кучи legacy, который порой просто не реально заставить работать с чем-то боле-менее современным;
- в последнее время (по крайней мере в моей конторе) наблюдается какой-то сдвиг в сторону Agile/SCRUM/Kanban, но как правило — это waterfall;
- большое количество external'ов, которым как-то до «командного духа» глубоко до фени: наняли на какой-то проект, он его сделал и свалил — а дальше начинается ад поддержки internal'ами...
- часто есть миллион внутренних процедур и, чтобы даже «попробовать» что-то новенькое, надо пройти очередь согласования и прочего
Итог: я не хочу никого отговорить идти в финансы, но таки иметь в уме эти минусы полезно, если вы привыкли к самым последним «фишкам» — вполне вероятно, что придется откатываться лет так на 3-5 в области некоторых софтовых технологий.
Я поработал на многие банки, и нигде не видел такого, чтобы было сложно согласовывать, если хочется попробовать что-то новенькое. Единственное, что на самом деле нужно — чтобы это новенькое решало реальные проблемы бизнеса. Если это условие выполнено, то никакие процедуры согласования никогда не мешали. Это иногда верно даже для compliance, которые в общем-то денег не зарабатывают, но бывают вынуждены делать проекты быстро, чтобы соответствовать изменениям со стороны регуляторов, в установленные жесткие сроки.
Впрочем, да, слышал и про обратное — когда местами сидят скажем на EJB 2, что с моей точки зрения нонсенс, потому что разработчики тратят время и деньги на то, что можно было давно уже вовсе не делать.
А что до legacy — так тут дело в том, что банки и биржи вообще начали автоматизироваться давно, и уже накопили много разного софта, который работает, и который никому не хочется переписывать. Да, бывают проекты, где его нужно поддерживать — но это как правило становится ясно уже на первом интервью, или даже до него.
Впрочем, да, слышал и про обратное — когда местами сидят скажем на EJB 2, что с моей точки зрения нонсенс, потому что разработчики тратят время и деньги на то, что можно было давно уже вовсе не делать.
А что до legacy — так тут дело в том, что банки и биржи вообще начали автоматизироваться давно, и уже накопили много разного софта, который работает, и который никому не хочется переписывать. Да, бывают проекты, где его нужно поддерживать — но это как правило становится ясно уже на первом интервью, или даже до него.
придется откатываться лет так на 3-5 в области некоторых софтовых технологий
Это ещё ничего. Я бы даже сказал, что это скорее уровень обычной компании, в которой присутствует инертность и скептическое отношение ко всему новому.
В прошлом году проходил собеседование в один банк, так там мне пришлось бы откатиться лет на 10 и вкладываться в изучение технологий, которые не поддерживаются и не пригодятся мне в будущем.
Sign up to leave a comment.
Чего разработчику ждать в сфере финансов: условия работы, проекты и необходимые навыки