Which cryptographic algorithm would they want to use?
That will really depend on the situation. To select the algorithms one should ask himself (at least) the following questions:
Which standards do you trust? Which standard do you have to use? What computations can you afford?
Symmetric, or public key based?
It again depends on the situation. Usually you'll use a combination of both, however there are valid use-cases for using only public key cryptography (usually extremely short messages) and for using only symmetric cryptography, usually when performance is a constraint or when a shared secret has already been established (i.e. with embedded devices or in a session resumption scenario).
Also what type of algorithm suites best and in what key size?
The algorithms really depend on the situation given. Generally however, 128 - 256 bit symmetric encryption, 256 - 512 bit hash functions, 256 - 512 bit elliptic curves and / or 2048 - 4096 bit classical asymmetric cryptography (RSA, DSA, ...) is in use.
Considering your third paragraph:
In a nutshell, you're right. You first negotiate a symmetric key using asymmetric cryptography (RSA or (EC)DH) and then use symmetric crypto to protect your payload. What you described is basically opportunistic encryption, because neither party takes measures to ensure the authenticity of the other party. This means a man-in-the-middle attack would certainly be possible and thus an active attacker could break the scheme.
Is there a safer way?
There is: Transport Layer Security (TLS).
TLS is the standard solution for secure real-time data transport and even has some nice security proofs. TLS can take care of all the situations you can possibly encounter: You can use a pre-shared key, you can authenticate against a server with a password (via SRP), you can use a certificate (or just a public key) for only one or both parties and even is widely deployed with famous libraries being OpenSSL, LibreSSL, BoringSSL, ....