I wonder why though if they are focusing on high performance trading applications they are using C# and .NET? The performance is fine for most applications, but C# just like VB.NET and Java, are all interpreted into a sort of byte code that runs in a virtual machine.
This is easily explained: You misunderstand how the .Net Common Language Runtime works. C# and other CLR languages are compiled into a sort of byte code. That byte code isn't executed through interpretation, instead the CLR compiles it into native instructions which are then executed. The same is basically true of most Java these days.
My understanding is that high-performance trading applications have many moving parts. Some of them are extremely performance critical, others less so. Execution speed and consistency is important, but so is individual and team productivity, turn-around time, and other software engineering priorities. Perhaps a function will run faster coded in C, but it may take twice as long before it compiles and executes without obvious error, and what happens if, someone mishandled some pointer math and the thing buys 1M shares when it should have sold 2M? Perhaps C# would have been a better choice after all.
Also, note, this job listing clearly states that this job is for desktop trading software used by account managers, etc.
As for the CS or EE requirement. Who knows, who cares? It could be thoughtless crap. It could be an attempt to skew the applicant pool in a particular direction. Job listings provide potential applicants clues what the employer really wants, and how they think about the job, but they shouldn't be taken absolutely literally, because chances are, the employer isn't sure what they want, or if they are, they aren't sure how to get it. So, they do their best, see what they get, and then go from there.
I will say that the people I know who have worked on user facing software for financial services haven't had CS degrees, or EE degrees. One has a degree in English, the other in Philosophy and the third in Classics. All at least as valid as qualifications for such work as a CS or EE degree, because often, the hard part of software isn't the algorithms, or data structures, or any of that, its understanding the people using them and the organizational context in which they work. In other words, its about figuring out messy humans. The code doesn't matter if no one uses it. The code doesn't matter if it confuses the users and/or sets them up for mistakes.