Depends on what kind of problems you you find interesting, but since it's so close to the metal, and since people want their kernel to be fast, there tends to b

Depends on what kind of problems you you find interesting, but since it's so close to the metal, and since people want their kernel to be fast, there tends to be a lot of clever algorithms, intricate locking, architecture-specific considerations, dealing with the hardware, all sorts of pretty interesting things you wouldn't usually find in regular business logic. Take filesystem code for example. It can sound like a conceptually simple and well trodden topic, but if you try writing one there's a pretty large design space and tons of interesting problems to try to solve. And then because of concurrency and the need for performance, there can be very intricate locking to the point it can be challenging to hold the whole model in your head all at once (you can have truncates, writes, mmap, all sorts of very different operations in flight in parallel that interract in funny ways). Or memory models. Reading memory-barriers.txt is a lesson in humility, I believe you can count on your fingers and toes the number of people in this world who can truly claim intimate familiarity with all the corner-cases and details implied by the model in that little text file =) But take practically any big subsystem of the kernel, and there tends to be plenty of interesting domain-specific problems and challenges.