This is all my experience/opinion, gathered from working in the field pretty close to the metal:
"embedded systems" are usually situations where you have significant non-trivial memory or speed constraints as compared to desktop systems. Those embedded situations can include microcontrollers, but can also include x86 systems on a chip, and also systems like PC104 or other form factors. They can run a "common" OS like Linux or Windows CE, but not always. They usually have a lot less memory and speed than desktop/server applications, but usually not so little that you have to think long and hard about whether to use a 16 or 32 bit integer for something like you might have to with a microcontroller.
The raspberry pi for example runs at 700MHz and has 256 or 512 megabytes of ram. An Atmel ATMega32U4 microcontroller for example runs at up to only 16MHz, with only 2560 bytes of ram. Some of the STM32 devices, which utilize an ARM cores, run at up to 24MHz and have about 8 kB or so of ram. Quite a substantial difference in speed and memory between the two, even more dramatic than a desktop vs a raspberry pi.
Programming for microcontrollers is a subset of embedded systems with even more significant memory and speed constraints, but also closer intimacy with the hardware the microcontroller is wired to. You'll spend a lot more time thinking about falling or rising edge clock triggers, watchdog timers, external interrupt triggers, analog to digital conversion timing issues and a bunch of other stuff that is typically long abstracted away in desktop systems. You may even have to be mindful of how much power is being used in different operations, and have to write your software to meet power draw requirements.
Until you have programmed for microcontrollers, it is unwise to claim you can. Until the day comes that you have to use an oscilloscope to figure out why your SPI-bus peripherals aren't talking, you don't yet know the kinds of things that have so far been invisible to you.