Many systems today employ an RTOS of some kind, and therefore end up with multiple threads of execution, so it's important to make sure that the WDT accounts for the proper operation of the entire system. Simply kicking the hardware watchdog in the RTOS's idle loop is generally not sufficient to guarantee that a system is fully functional. A thread stuck in an infinite loop, for instance, would not necessarily cause the WDT to expire. 

A technique I've used for years is to create a variable that holds a bitfield representing each of the running threads, and then only kick the hardware WDT when all the bits are set. It looks something like this (some details omitted):

#define  THREAD1 0x01 // arbitrary thread names here
#define  THREAD2 0x02
#define  THREAD3 0x04
  … 
#define  THREAD_MASK (THREAD1 | THREAD2 | THREAD3 …)

static  uint8_t wdt_accum; 
void  kickWDT(uint8_t thread) {
disableInterrupts();
wdt_accum  |= thread;
if  (wdt_accum == THREADMASK) {
   <do  whatever it is that kicks the hardware WDT>
wdt_accum  = 0;
}

enableInterrupts();
}

Using some linker magic you can place the wdt_accum somewhere in uninitialized memory where it can be read at startup to narrow the cause of a WDT event down to the thread involved. Usually that's sufficient to quickly locate the problem. Of course, if the hardware supports steering the WDT event to a non-maskable interrupt you can also save the effective PC, or even some portion of the stack, of each thread to get closer to the point of execution when the WDT expired.

Reading the comments regarding Assembly in your latest Embedded Muse made me wonder if your readers have heard of Compiler Explorer (https://godbolt.org/).  It is a tool that takes higher level code from C/C++ and other languages, runs the a compiler on it, and shows the assembly results. While it's primarily tailored towards x86, when it comes to C/C++, it has nearly every GCC/Clang flavor, including ARM32&64, MSP430, and RISC-V.  Also, since it's completely open source, it's possible to download and make it work locally with any compiler that outputs assembly.  I've found it to be an invaluable tool to see what the compiler does under the hood and to quickly play with newer language concepts I don't quite understand.

As a Baby Boomer, I found myself behaving much more like an Gen-Xer in that I switched jobs fairly frequently (every 3 years or so) during my early career.  Later, I found employers who were better at offering a breadth of experiences.  

My conscious choice was to alternate between technical, technical management, and customer-facing responsibilities in my job assignments.  This led me from Bell Labs to large pharma companies, with stints at start-ups and small businesses along the way.  At various times I was a software architect, a software development manager, a technical marketing manager, a patent and trademark administrator, an applied mathematician, etc.  

I started with Z80 Assembler (hand-coded through a hex editor), and picked up BASIC, C, PL/M, PL/SQL, Haskell, and F# along the way.  I never advanced beyond "Senior Manager" grade in a company (never interested in doing so), and retired six years ago to a very active post-retirement life doing intellectual property consulting, personal projects with Raspberry Pi, Arduino, Atmel, and CMM2, and board of director positions on community arts organizations.

As Robert Heinlein said, "Specialization is for Ants"

My suggestion would be to look for employment in smaller companies or startups. These tend to require people with a larger range of skills, and ask employees to cover a wider range of roles.

There are dangers though that the company _may_ be more likely to go out of business or _may_ get swallowed by a large company that then imposes its own idea of who does what. Or just grows to become a larger company with specialists.

I would suggest they look into: 

1.  Consulting work, either as a sole proprietor after obtaining their PE or with a product design firm.  I believe there are opportunities to face a wide variety of challenges from different products which they might find interesting.
2.  Research, specifically things involving material science or chemical engineering.  The future of which will require extensive process control challenges which are highly dependent on both mechanical/electrical/software choices for the design.
3.  Start their own product design company.  A friend of mine designs peanut dryer controllers for farmers and faces challenges in both mechanical and electrical design.

At 10 years old, in the 70's, I walked into a Radio Shack and was fascinated.

The first step was resistors and LEDs. The next step was a BCD counter kit, 277-103. It was a steep ride downhill after that.

I used to joke that I knew the catalog numbers for most of the parts and their prices.

The G&T program in junior high school exposed us to programming.. on a Radio shack TRS-80 Model 1 level 2 and a Model 3. TRSDOS anyone?

At the age of 13, I moved to a house with a junk yard nearby. Our local telco was moving from relays to the ESS system, so there were mountains of parts to be had.

In those days, there were also tons of vacuum tube televisions parked by the road, and so I also had lots of fun with them.

When it was time for college, I do not recall taking any other profession seriously. I earned a BSEE from Pitt, but also added the PA P.E. certification soon thereafter.

But at 29, it became crystal clear. I had been adopted, which I did know. And then my maternal side found me. My grandfather had also been an engineer, a P.E., worked for himself, and I had his hair and body type.. all of which I had done before they found me. A former colleague of his even said that I had his mannerisms.

I also heard of his health record, but did not listen carefully. I later tracked his heart history to the letter, and survived two heart attacks. Turns out that sitting for a living is not very good for us.

Nature versus nurture??

Regarding the question "What childhood experiences influenced you to become an engineer". My answer parallels yours to some degree. As a boy I was always "building things" initially out of wood but out of metal later. When I was about 8 or 9 a neighbour coached me on how to make a Morse code transmitter out of a Model T ignition coil. (Very illegal but then I don't think I knew.)

My father was not an engineer, he ran a small town repair shop in SK. However he was very smart and could design and  build things out of metal. Before I was a teenager he had me helping him in the shop. (This was a bit like forced indenture.) However it was there I learned how to repair engines, do simple lathe work, use an arc welder and an oxy/acetylene  welder to braze or weld. I guess it was with him that I learned what a good work ethic was. When I was in my teens before I was allowed to drive I built a gas powered go-kart mostly by myself. After highschool I worked at a natural gas compressor station. It was here that a technical school electronics grad impressed me. This led me to enroll in a technical school electronics program. It was here that one of my instructors impressed me, he was an engineer. That led to enrolling in an EE program and then in an MSc program. From the MSc program I landed an instructor position in a large technical school where I stayed until retiring. It was in the technical college where I learned Assembler programming for 8080, 8088, PIC and HC11 micros. Later I moved to programming micros in C. To this day I still "build things" mostly with micros in them.