Even if you do work on Windows in-box code only, it might not be so easy. Here's another issue you raised with your old job:
> 2. Debugging exclusively via metrics and logs, since I can't just attach a debugger to a running server.
I find debugging Windows issues fun, but it might not be for you. On rare occasions, you might be lucky even to have telemetry and logs, for customer issues that can't be reliably reproduced. "We noticed that 30% of our module's crashes in the last Windows Insider Preview Dev build had this new stack, so we used Watson Portal to request more crash dumps from devices that ran into that particular crash, and a week later, we've accumulated this set of dump cabs...."
On the other hand, if you get an automated email saying "test case XYZ broke due to a crash in your module", you'll probably get a live kernel debugger remote - an email link or copy-paste command to open a kernel debugger on the dead VM, preserved for your debugging. But of course, bugs aren't necessarily caught that early, and even if they are, finding things via kernel debugging is a needle-in-a-haystack problem because you're debugging the entire computer, not just one process.
I think what I meant to say is that sometimes even telemetry and logging is unavailable to you. In my example, you might ask for more dumps for your Windows component or Microsoft first-party app on Watson Portal / Get More Data, but even after a few days of waiting you don't get any more, or only one more, because the issue occurs in the wild too rarely to show up in telemetry, or repros often but doesn't reliably produce a useful dump.
As an aside, if you are a third-party Windows application developer, I highly recommend you register your apps with the Windows Desktop Application Program: https://docs.microsoft.com/windows/win32/appxpkg/windows-des... - this will give you access to the same app reliability telemetry, including user-mode crash dumps (.DMP / .CAB files), that Microsoft has. This is only the latest of several iterations of this data access over the years, but it and its predecessors are still badly underused in my non-Microsoft experience.
Yup, this all sounds very familiar to me - and I never worked on anything Windows.
The "repros often but doesn't reliably produce a useful dump" is particularly frustrating. Like, you're seeing all those crashes, and every one of them is likely to be some poor user who is at best annoyed, and at worst just lost some data. And you have no clue as to what the bug is or how to fix it to help them.
> 2. Debugging exclusively via metrics and logs, since I can't just attach a debugger to a running server.
I find debugging Windows issues fun, but it might not be for you. On rare occasions, you might be lucky even to have telemetry and logs, for customer issues that can't be reliably reproduced. "We noticed that 30% of our module's crashes in the last Windows Insider Preview Dev build had this new stack, so we used Watson Portal to request more crash dumps from devices that ran into that particular crash, and a week later, we've accumulated this set of dump cabs...."
On the other hand, if you get an automated email saying "test case XYZ broke due to a crash in your module", you'll probably get a live kernel debugger remote - an email link or copy-paste command to open a kernel debugger on the dead VM, preserved for your debugging. But of course, bugs aren't necessarily caught that early, and even if they are, finding things via kernel debugging is a needle-in-a-haystack problem because you're debugging the entire computer, not just one process.