| I work at Apple on the kernel team. Congratulations on the job! Getting into kernel development is very difficult. You said you were looking for things that you might not like about kernel development, so here’s a few: - Distributed systems. Everything is distributed these days with NUMA, cache coherency, PCI transactions, etc. You’ll have to know how to use the right kind of atomic memory ordering, debug lockless algorithms, and know how the OS scheduler works at a deep level. If this doesn’t excite you, the job might not be a good fit. - Working with physical hardware. Although in most cases you can get away with a VM, you will almost certainly have to use an actual device for some of your work. The hardware you use might not be 100% functional or even correct- I’ve had to debug kernel issues that ultimately were hardware errata. At Apple it’s easy to get in contact with the silicon design teams, but I’m not sure about Microsoft and Intel/Qualcomm. Working with physical hardware also limits your ability to work remotely easily. Lugging around a bunch of laptops, phones, and tablets in a carry-on suitcase is no fun, especially when you have to take them all out at TSA checkpoints. - Lack of user-visible impact. Kernel dev is vitally important but it doesn’t get much visibility, except when something goes wrong. New kernel features hardly make the headlines. It can be a little annoying to see your colleagues in app/web dev get recognized for the features they worked on at WWDC or Microsoft Build, while you’re toiling away working on kernel features that very few people care about. - Debugging. I actually think debugging kernels is not too difficult if you have the right set of tools. At Apple we use lldb and hardware debuggers (JTAG/SWD), and have the ability to take a core dump of the kernel after a panic to analyze later. But since kernel dev is at the core of the operating system, you’ll have to learn to debug other parts of the stack too. For example, you might make a kernel change that breaks the file explorer but only when you visit a specific directory. So you’ll need to know how to debug both the user space process to know what’s going wrong, and the kernel to know why that is happening. Although there are some negative aspects of the job, there are many more positives. I really like my job and can see myself staying at Apple for many years. I’m constantly learning and working with some of the smartest people I have ever met. Give the Microsoft job a shot; you can always leave if it’s not a good fit but you will have left a better engineer than when you started. |
I'm familiar with the things you mentioned, except PCI transactions. In this context, do you also have to deal with distributed transactions, lost responses, eventual consistency, and the like? Do you have to account for "response lost, don't know if it went through" situations?
Definitely going for it after all the responses here :)