Category Archives: Jobs

Murex performance – is the system slow?

Murex performance: Is my system slow or is it just me? When you present the system to new users, it is a question you often hear.

There are many answers which can come up:
– Yes
– No
– Maybe
– Server is a little small
Etc…

But the only good answer is: “It’s all relative!”.  Indeed, what do you call slow or fast mostly depends on the user.
For instance, if opening a trade ticket takes 3s, is that slow? is that fast? Agreed, if it takes 2 minutes, it is slow!

So the problem with performance is that there is a big amount of subjectivity. But I don’t want to pretend or even try to do psychology and check what the human mind considers slow or fast. On the contrary, I’d like to take precise examples of what users frequently report:

– Actual session start. Since the new GUI, login, password, group are almost instant, but the actual session start when you enter a menu usually feels slow
– Opening details: bonds, trades, counterparts, etc…
– The feeling that the system is sometimes a bit sticky, where actions take 1s or so when you expect them to be instant
– Simulation loading
– Accounting generation
– Saving trades

There are, in my opinion, 2 types of Murex performance issues: the user experience type and the structural ones. One could argue that they’re both the same but let me explain:

The UX ones are the ones which 1s or 2, for which timing is hard or imprecise. In the list above, I’m referring to opening details, stickyness. This is usually this type of performance which is ignored as 1s to open a trade or .1s does not seem like a big change to the user. But what the user does not always understand is that when you press space bar to open a deal, lots and lots of things are happening in Murex: the trade number is sent from the client to the application server. And then the application server is sending DB requests to get all information. It is not one single request, we’re closer to hundreds than few ones: get trade header, get trade body, get contract details, get additional flows, check access rights. If we assume that the communication between the DB and the application is 3ms, 100 requests bring that to .3s, add the CPU time (to decide if the trade is part of a package, requires to open other tables), add actual request time from the DB and then sending all the information back to the client. And here you go 1s, 2s are very easily reached.

So the User Experience performance issues are also structural and there’s not much to do in terms of code optimization. (well, at least not in my non PAC-brain).

The actual structural ones, the ones you expect to be slow are basically like the above compounded many times, factored with extra calculation for risk. The good thing is that when you get to that level, you can usually find optimizations on the DB side when not on the code side to improve speed and loading/processing more information at once. Usually when you can contact support for Murex performance, people expect to help on this kind of issues.

So back to our original question: is the system slow? It is indeed relative. There are implementation of Murex where the system is lightning fast. But everything has been optimized with that objective. To get your ping times from 1ms to .1ms is no small feat, to have a large DB and very fast requests require massive and optimized DB power, etc… So it can be done and has been done, but people tend to be cost sensitive, so doubling (well, I suspect far more than doubling) your hardware/maintenance budget so that a trade does open in .1s instead of 1s does not really make sense.

And Murex also works hard in terms of improving the user experience where they can: Livebook is a great example. Livebook means that data is churned all day long by processes so that when you enter Livebook in place of simulation, you don’t wait 5-10 minutes but some seconds to have the information; screenset is another great example, defining screensets lets you have all the sessions you need opened in one go rather than starting them one by one.

To conclude, Murex performance is addressed where Murex can do something or think of something innovative. But there are some limits due to hardware that are next to impossible to improve from a Murex point of view. So Is the system slow? No, Murex worked and is working hard on it but in the end, it all depends on your implementation and how fast you want (can afford) it to be.

Murex interview – What NOT to do

During my time at Murex, I had to recruit quite a few people and I faced different profiles, so have a read, smile and relax. For an interview you need to be prepared and at your best. So here are some pitfalls you can easily dodge.

Murex Interview – The Test

There is a test! Yes, it’s best to revisit your finance/programming/math lessons so everything is fresh and handy in your mind. You have 1 hour to do your best.

I think I have to give the golden crown to one candidate (to whom I already told there was a test): he came in, sat in the room and I left him to work on his test. 10 minutes later, he came out, handed me back the test (nothing written on it, not even his name, perfect to give to the next candidate). “I don’t think I’m suited for this role”. At least he was honest.

Second place goes to someone we ended recruiting because that person is actually really good. But when asked to give a simple definition, there was actually a fair bit of writing. 1 page! In small characters when 1 sentence could have sufficed. Know that we discuss with you the answers you give and we can easily tell if you understand or not

Last place goes to the bullshitter. Answers were very generic and could not make much sense out of them. When asking him for more details, he told us that he did not believe that it was so important to know things in details, you can always talk your way out. Well, he managed to talk his way out of the interview.

Murex interview – Presentation

Job interview is a two way street, you discover the company and people who are looking to recruit BUT they also discover you and who you are.

Once we had this candidate who was just looking at the table, did not even look at one of us once. And his answers were short when not single worded. Not matter what we tried to get him to relax, we failed miserably and we could not get him to open up. As many Murex roles are customer facing, being comfortable talking to people is important!

When you present yourself, it’s important to explain why Murex is of interest to you and especially on the longer run. Some people (yes it happened more than once) were upfront enough to mention that they were looking at Murex just as a stepping stone in their career. Definitely not a smart move!

Murex interview – The good surprises

But sometimes you get good surprises. The feeling (usually straight away) that you found a gem, someone that would fit perfectly the bill. And the interview/test will effectively confirm it.
I often pondered if it was simply the first impression that decided how an interview would go but I do believe that the Murex test makes things actually fairer. Someone with very good presentation but lacking knowledge would effectively be at a disadvantage after the test. Someone not so good at presenting can gain some confidence and feel more on familiar ground thanks to the test.
After that if you’re not good at presenting and don’t know much, maybe it’s better not to take the interview!

 

Scoring a job with Murex

In the continuation of the previous post, here are details as to how the interview process works and what is expected of you.

The level required by candidates is actually very high, this ensures people who can learn quickly but also it builds a company spirit where you are surrounded by very good people. This is very motivating.

For graduates (or non senior positions), one of the first things that happens during the recruitment is a knowledge test. Depending on the type of job you’re applying for, the test might vary. Without detailing what the tests can be about, the idea is to test what you should know (maths, financial questions if you studied finance, programming if applicable, etc…) but also how do you think and if you have the good reflexes when faced with a problem.

So for more junior people, revise what you have studied and also try to understand what Murex is about (this website and Murex website will be good sources of information).

If you manage to get a job, you will receive trainings from Murex about basics (what’s a rate curve, what are the different type of options, what are accounting entries, etc…) the idea is to ensure that even if you are not working in a particular domain, you have a basic knowledge as to what it is. The trainings then move to specificities of Murex and how the software works, the internal processes, etc…

While the training takes 6 weeks to 2 months, Murex tends to consider that the investment in someone starts to pay off after 18 months, once you build confidence and knowledge. There will be lots of things for you to do prior to that but you’ll be well assisted to insure you learn as quickly as possible.

As 18 months is a significant amount of time, it is important for Murex to recruit the right people, hence the focus put on the recruitment process.

For more senior positions, this is of course on an ad hoc basis given how well your skills are transferable.

More questions, feel free to comment or go to the forums and I’ll try to answer them

Murex teams

Murex people are split into many different teams and sometimes it is not obvious which team does what. Let me detail the different teams here:

– Dev teams. This is the team customers will never talk with. Their jobs is of course to develop new features but also correct bugs and other issues. Most of the development is done from Paris.

– PES Teams (Product Evolution Services). These teams are the main interfaces between business and developers, they’re split by asset class or activity (processing for instance). Their job is to build the development roadmap with developers, write specs, test new functionalities, present roadmaps, assist other teams with asset specific questions. They’re often on the front line for presenting the software as they have a strong understanding of the business needs and the software. Location wise, they’re mostly based in Paris along with developers.

– CES Teams (Customer Evolution Services). These teams are in charge of following customers. They’re usually the first point of contact for customers and will follow internally on what a customer needs. Outside Paris, most consultants are classified as CES as they’re all customer facing.

– PAC team (Performance and Architecture). They have multiple missions: work with the dev team to agree on the architecture to be adopted by the software: services, modules, technology used,… but also monitoring and improving the performance of the software. For example, ensuring that the software could cope with a large volume of transactions without slowing down (FX cash business) is their work. They’re also tasked with assisting customers in choosing the right hardware and producing performance tests.

– Operate. This team works 24×6 (if not 24×7) and is a second line of support for Murex teams. They have a large knowledge of the application and assist the other teams in many ways (building a new environment, tracking a crash, etc…)

– QA. The team is mostly based in Beirut and crunches through all the reports generated everyday tracking any regressions or undocumented change.

– Release management. Their job is to ensure that the software patches and versions are released on time.

– Bizdev. This one encompasses:  pure bizdev people on the lookout for new opportunities, following on prospects and account managers who are tasked with building a strong relationship with the customers.

– MTEK team. Murex documentation team, ensuring that all documents are of high standards, properly formatted and of course available to all customers.

– CDS (Client Delivery Services). This team follows projects and provide everything project wise from mandays to achieve tasks to project management and solution architect.

I have likely omitted some other teams (and I apologize to them in advance) but these are the main ones and which are mostly specific to Murex. I suspect that everyone knows that Murex has a Marketing, Accounting and legal departments!