TL;DR: Firmware, bootloader, kernel, initramfs, then init (systemd) bringing up targets. Identify the stage from the last thing on the console: no bootloader means firmware or disk, a kernel panic means initramfs or drivers, and a hang after that is almost always systemd waiting on a unit, usually a filesystem in fstab.
How to approach it
Give the stages in order with the symptom each produces, because this question is really "can you narrow a dead server to one layer". Then mention fstab explicitly, since an entry for a device that no longer exists is the single most common cause of a machine that does not return from a reboot.
A strong answer
Firmware (BIOS or UEFI). Powers on, initialises hardware, runs its self test, and hands off to a bootloader from the configured boot device. Nothing on screen at all points here, or at the disk not being visible. On a cloud instance this is where you check the console output and whether the root volume is attached.
Bootloader (GRUB). Loads the kernel and the initramfs into memory and passes the kernel command line. A GRUB prompt or a grub rescue shell means it found the disk but not a valid configuration or kernel, typically after a failed kernel update or a changed disk layout. This is also where you edit the boot entry to add single or systemd.unit=rescue.target for recovery.
Kernel. Decompresses, detects hardware, mounts the initramfs as a temporary root. A kernel panic here usually means the initramfs lacks a driver the root filesystem needs, which is what happens when a storage driver or an encryption module was missed after a kernel upgrade.
initramfs. A small temporary root containing just enough to find and mount the real one: storage drivers, LVM, RAID assembly, LUKS unlock. Then it pivots to the real root filesystem and hands over to init. Dropping to an initramfs shell means the root device could not be found or mounted, and the message just before it names the device.
systemd. PID 1. It brings up units to reach a target, ordinarily multi-user.target or graphical.target, starting things in dependency order and in parallel where it can. This is where most reboot failures actually live, and the usual one is a filesystem entry in /etc/fstab for a device that is no longer present. systemd waits on it, and the default timeout is 90 seconds per mount before it gives up and drops to emergency mode. Adding nofail to non-critical mounts in fstab is what prevents a detached data volume from holding up the whole boot.
Once you have a shell, the commands that matter:
systemctl --failed # units that failed
journalctl -b -p err # this boot, errors only
journalctl -b -1 # the previous boot, if it got far enough to log
systemd-analyze blame # what took the longest
systemd-analyze critical-chain # the dependency path that decided total time
systemd-analyze blame is also the answer to the follow-up about slow boots, since it ranks units by startup time directly.
For a cloud instance that will not come back: read the serial console output first, because it shows the stage. If it is a filesystem problem, detach the root volume, attach it to a working instance, fix /etc/fstab, and reattach. That procedure is worth being able to state, because it is the recovery for the most common case.
What interviewers probe next
"What replaced init scripts and why?" systemd, for parallel startup, proper dependency ordering, socket activation, and supervision with restart policies. SysV init started things in sequence by number, which was slower and expressed dependencies only as ordering.
"How do you boot into single user mode?" Edit the GRUB entry and append systemd.unit=rescue.target, or emergency.target for a more minimal shell before filesystems are mounted.
"What is the difference between a target and a runlevel?" A target is a named group of units. It replaces the numeric runlevel and there are compatibility aliases, so multi-user.target corresponds to runlevel 3.
Common mistakes
Adding a mount to fstab without nofail, so a missing volume blocks the next boot for 90 seconds and then drops to emergency mode.
Skipping the console output and trying to fix a dead instance blind.
Confusing a kernel panic with a systemd failure. One is before the root filesystem is mounted, one is after, and they need different recovery.
Rebooting after a kernel update without checking the initramfs rebuilt, which is how a driver goes missing.