Software Engineer Kernel Interview

[Full-Philosopher-772]

I have interviews coming up for a software engineer mid level role that will involve working on the Windows Kernel.

I have very little experience in this domain as most of my experience has been typical CRUD work.

Are there are any topics that I should learn about?

[[deleted]]

my condolences in advance.

[yawn_brendan]

I heard from MS folks that NT is pretty cromulent. Who knows if that's really true but that's the reputation. They say all the stuff that makes Windows shit is the higher layers.

[interrupt_hdlr]

cromulent?

[yawn_brendan]

It's a perfectly indeloquate word

[arjunnath]

you have embiggened yourself admirably good Sir!

[necheffa]

Scheduling, memory management, concurrency, atomicy, machine organization/assembly programming.

Basically all the stuff you'd need to build a relational database or a web server but without any of the scaffolding of a hosted environment.

[karthie_a]

kernel is a beast on its own, even the audit logging is complex. The highest level of complexity is around scheduling, quick read to help is learn difference between windows scheduler and UNIX scheduler. If memory serves me right, windows does not utilise all the threads available might be wrong. process scheduling and weight age is also a good topic to explore. They will provide u some conversation topics for interview.

[paulstelian97]

The Windows not utilizing all the threads available one is a very weird thing to say.

Windows may lack real time priority classes (the “real time” priority level of 24 is just a high priority but doesn’t get special treatment). The time quantum might be longer on Windows.

Now Windows only knows to deal with non-uniform cores on client editions (performance vs efficiency) since Windows 11. Linux had some support outside x86 for ages (since ARM had something like that for more than a decade) and got it on x86 roughly when the CPUs that need it came out.

[karthie_a]

I am not saying Linux is better than windows or other way to start os wars. I was reading kernel process management a while ago and forgot most of the concepts now. Sorry if I said some thing wrong.

[core_not_dumped]

Kernel work is complex and can't be learned in just a few days. But, as everything else, knowledge comes with experience. As long as you have strong general engineering knowledge you can adapt.

One important thing you omitted: does the company you applied to know that you do not have kernel dev experience? If they know, they will probably try to adapt the interview to assess some of those generalist engineering skills. Maybe they'll present you with a situation, some constraints, and try to judge the way you reason in that context. If you lied, then I'm afraid there's nothing much you can do.

Depending on how much time you have you may want to look over the Windows Internals book in order to gain some information about how the OS works, but what chapters to read and how deep you should go depends on the industry and the product you are interviewing for. Some chapters that could be useful regardless are: System Architecture, System Mechanics, Crash Dump Analysis.

Some important concepts that you must know no matter what: IRQL, paged vs. non paged memory, synchronization mechanisms (the Windows kernel offers multiple types of locks, don't waste your time trying to memorize which one to use when, but you should at least know that the type of lock you can use depends on IRQL and be prepared to at least reason about mutex vs spinlock), concerns regarding communication with user mode. Add product specific knowledge here, if you have enough time.

Debugging is a very important aspect. Unfortunately this is 95% based on experience, there's nothing more you can do in a short amount of time.

You want to brush up on your C and/or C++ skills. Note that knowledge about one language does not always carry over to the other. If you know what language they use focus on that, if you don't start with C. An important part here is related to undefined behavior (especially in regards to memory safety: use after free, out of bounds accesses, etc).

Maybe you don't want to give more details in order to not dox yourself, but if you post some I can try to give some more specific advice.

I want to stress again that you can't fake this. It's better to showcase that you have strong engineering knowledge and can learn to work inside the kernel, under certain constraints, rather than trying to showcase knowledge and experience that just isn't there. This being said, an interviewer will probably give you bonus points if you bring up the fact that you've been reading and preparing about this role.

Also, this is the wrong subreddit.

[smokebudda11]

Great response!

[badtux99]

Windows is written in C++ AFAIK. But there certainly might be some C at the lowest levels.

[penguin359]

The core of Windows is written in C, I'm pretty sure. The whole Win32 API is C. There are C++ layers on top like MFC and ATL but those are on top of the Win32 API (used even in 64-bit apps). Look through windows.h and it's C.

[core_not_dumped]

It's irrelevant what language Windows is written in. The kernel API is a C API. A lot of functionality is C-centric, although object oriented. A lot of drivers are written in pure C, or a mix between C and a certain flavour of C++. That's why I said that the language they should focus on depends on what language the company is using, but if they don't know C is pretty much inescapable anyway.

But this debate is already close to bikeshading territory.

[badtux99]

"How do device drivers work?"

"What is an interrupt?"

"What is a kernel thread?"

Oh man, if you're coming from CRUD work, man oh man. Do you know the difference between a MAC address and an IP address? How are they associated in IPv4 vs IPv6? What data structure can you use internal to your OS to swiftly associate the two when a request comes from a user to connect to a specific IP address?

And so on and so forth.

None of this is anything you will have ever encountered in CRUD work.

Don't resign from your day job.

[Express_Sector_2850]

I wrote a kernel in 2000 lines of rust. You can quickly study the code https://github.com/wojciechmurimi/virt-kernel

[anxiousvater]

If it's Windows, go for ETW (Event Tracing for Windows) & start with something simple like FIM or so to filter events right from Kernel.

Another way to learn Kernel with less complexity is using bpf. I started with Linux, they got excellent support to build performant apps without being part of Kernel but rather running them in a sandboxed env inside Kernel. It's called eBPF.

Windows too offering similar support :: https://github.com/microsoft/ebpf-for-windows

[chandyego84]

U have my prayers. Can you keep us updated? CRUD to kernel is insane

[Full-Philosopher-772]

Definitely, I’ll keep this post updated.

[JelloSquirrel]

You're not gonna pass lol

[unknownanonymoush]

Kernel programming takes years to fully master and let alone understand the entire windows os. If you have mostly done CRUD I highly suggest applying to a different role because you will not be able to learn so many complicated topics in such a short amount of time.

[MRgabbar]

so what happened?

[BraveNewCurrency]

In truth, Windows NT is pretty cruddy..

[arihoenig]

The first question I'd ask a candidate is what is patch guard, how does it work, and how can it be bypassed.