While a lot of tech is rapidly moving and constantly changing - this is the type of fundamental knowledge that will probably prove valuable for the rest of your career.
With an interpreter you can just probably ask the interpreter to stop at a certain instruction. For the purposes of your debugger the interpreter is the CPU in that respect. Except that you don't necessarily need to rewrite memory (although this probably exists too where the IL has a special breakpoint opcode).
With a JIT compiler you could do the same as in the article, but it complicates things because the code you want to debug may not have been jitted yet, or, with some JIT compilers, may not be jitted at all, ever (e.g. a small method that runs exactly once). You could also do the same as above, with a breakpoint opcode, or asking the runtime to break at a particular statement. Both cases require the JIT to play along and do the right thing. For code that isn't jitted you'd have to fall back to the interpreter anyway, though, so in some cases JIT compilation is simply disabled in the debugger (e.g. Java, if I remember correctly), which has the unfortunate side effect that not only you lose optimizations, which is normal for debug code, but you also get a hefty performance hit because you're now running interpreted.
See this explanation of how it works in SpiderMonkey, for instance: http://rfrn.org/~shu/2014/11/20/speeding-up-debugger.html
Of course, one needs to take care of the respective secure access. :)