"Yes, and..." is a wonderful rule-of-thumb in improvisational comedy. Not so much in the UNIX world.
When I run the admittedly silly yes& command, I cannot interrupt it. The terminal crashes or gets stuck into a loop.
I expect the yes process to be suspended immediately, since any process in the background should suspend if attempting to write to stdout, but it doesn't seem to be the case, and I'm wondering why.
Background processes which write to the terminal are only suspended if the TOSTOP output mode is set, which isn’t the case by default. Try
stty tostop yes & and you’ll see that yes is suspended.
Background processes which read from the terminal are suspended by default, because there’s no sensible way for them to get correct input.
See the section on accessing the terminal in the GNU C library manual.
With TOSTOP off, the terminal doesn’t crash or become stuck, it remains responsive to input; so you can stop the background yes by either killing it (kill % if it’s the only background job), or bringing it to the foreground (fg) and stopping it (CtrlC). You’ll have to enter commands blindly but they will work.
Stephen's answer is excellent, but I would add that you can regain control of your bash session by foregrounding the process, and then interrupting it:
$ yes & y y y y ... Although you won't see it, enter:
fgEnter and then Ctrl-C
fg is the job control command to move a backgrounded job back to the foreground, and of course, Ctrl-C sends a SIGINT signal to the current job. In cases where you have multiple jobs backgrounded, fg can be followed by a jobspec argument to stipulate which job you want to move to the foreground. Details are in the bash man page.
% would also work instead of fg to foreground the last backgrounded job.