"Real Time" has a well defined meaning in software engineering. One that has little to do with the job advertisement you saw. Real time is critical in control systems, you promise a hard upper limit on how quickly your program responds to an input event. The canonical example is the flight software for a rocket. When it veers off course, you better have an upper limit on how quickly you adjust the nozzle. Being occasionally a bit late doing this is not good enough, the code stops running when the cpu is vaporized in a spectacular half a billion dollar fire ball.
Which is the true engineering challenge, being on time every time is the hard problem to solve. A soft real-time system is on-time 99.9% of the time. Getting rid of the 0.1% rocket destruction mode requires a different kind of execution environment. Windows is often quoted as a non-real time operating system. Which isn't true, it is only non-real time in user mode. It has excellent response times to interrupts in kernel mode, assuming you can avoid getting a crappy audio driver installed. Kernel mode is however off limits for the friendly kind of execution environments such as provided by the CLR. And bugs in your code beget a blue screen.
The financial industry has a different definition of real time. More in line with the literal meaning: at least as fast as the stock broker's perception of time. The canonical example of a need for this is program trading. Software that listens to the stock ticker and makes very short term buy and sell decisions. The angle is that they take advantage of the changes in prices of financial paper. Intuitively: if the price of a stock is going up then buying the stock early and selling it an hour later gives you a profit. Money for nothing. Works the other way too, sell early when the price is falling, buy back later.
Traditionally done by humans. You've probably seen the scene, a large office with hundreds of people, each with a dozen monitors crammed in front of them. Staring at the stock tickers and trying to guess which way it is going. The edge is that you make the trading decision just a bit quicker than everybody else that is looking at the same data. The faster you respond, the more pennies you skim off my retirement account. To be competitive with the army of brokers looking at these screens you have to at least operate real time, coming up with the trading decision faster than the humans.
Taking longer than 'real time' is completely useless. You'd make trading decisions on stale data, stale by the amount of time you need to process the data. You'll be the one that everybody else makes a penny off. What matters little though is being late only 0.1% of the time. Yes, you'll typically induce a loss but it is a small one compared to the 99.9% of the time that you're faster. Or fast enough. As such, running your code on a non-real time operating system and in a VM with garbage collection isn't a problem. In fact, it is an advantage because software that ships sooner cost less to develop and makes money being in use before the competition's version comes online.
The real challenge in making this kind of code competitive with everybody else is being able to eke good decisions out of a mountain of data. That's where threading becomes important. You'll have to process the stock ticker data as soon as it comes in. That requires a thread. And detect significant changes, before everybody else does. That requires taking advantage of all multi-core cpu resources, done with threads.