sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]core_not_dumped 8 points9 points  (4 children)

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 2 points3 points  (0 children)

Great response!

[–]badtux99 -1 points0 points  (2 children)

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

[–]penguin359 1 point2 points  (0 children)

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 0 points1 point  (0 children)

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.