Systems programming is a generic term for a class of developer that is able to think about a complete piece of software that also includes the hardware that the software runs on.

Consider the following problem: you understand the application you're building and there are choices of what kind of hardware you want to use. For example, you can use a faster processor but that increases costs or you can use a slower process and custom ASIC's to improve overall performance. Understanding the behavior of your applications, understanding how your ASIC's will improve over time and understanding how to structure your software so it can exploit the ASICs and lower powered process and deliver better performance is the essence of great systems programming.

There are other skills associated to systems programming like the ability to debug concurrency, being able to design abstractions etc, but my belief is that modern applications require and demand similar skills. So I am not sure I would make those skills only the domain of systems programming any more.

Or at least that's how I think about it.

So how do you evaluate someone?

The first is to see what they have done in the past.

But what are some things to look for:

A good systems programmer will articulate choices in terms of his or her understanding of the underlying hardware limitations. For example, a good systems programmer can talk about how the CPU architecture and memory architecture drove him to pick some approaches over others. Also a good systems programmer understands how hardware is evolving and will recommend software choices that fit with how hardware is moving.

A poor systems programmer is virtually indistinguishable from an application programmer. He will talk about approaches that are divorced from physical reality. Hardware innovations will be happily ignored. Design choices will be made based on mathematical elegance instead of underlying physical realities...

So how do you go about finding a good systems programmer in an interview:

- Ask them to describe things they did in the past and see if they ever point out hardware limitations in their designs.

- Ask them about how different hardware choices would alter their designs.

A good systems programmer will be able to answer the questions quickly and thoroughly. A poor one will struggle trying to connect the dots between the changes in hardware and his design choices.