It often refers to programmers that develop things that other programmers use to construct applications. A systems programmer may work on compilers, operating systems, framework libraries, etc.
They will also often work with lower-level abstractions, such as threads, so that the higher-level developers need not think about them in their own designs.
Below system level you can harmonize (merge) branches of the same system (repository). At system level you would harmonize repositories - might involve politics I guess
Tree vs forest (more than one root)
Beyond systems level would be organic (system of systems)
For the purpose of job interviews (and not necessarily any kind of sound definition), this means that the position you are looking at will have you dealing with software that implements some operating system services.
To give you some examples: you might be working on an SDS product (software-defined storage), perhaps a filesystem, or maybe a network-attached block device etc. that operating system has a way of interacting with and exposing to other software as it's own service. To make it even more concrete: you can write a filesystem in a way that it interfaces with Linux kernel, and, once installed, users will interact with it through VFS interface (so, they don't even have to know they are interacting with your specific product). ZFS is a good example of this kind of software.
Similarly, it could be SDN (network), eg. various VPN software s.a. OpenVPN. Or a users / permissions management software (eg. LDAP server, s.a. slapd). Software to manage system services (eg. systemd). Software to manage specialized hardware (on top of drivers) that, again, provides its services through the operating system (eg. nvidia-smi). Or, maybe it's a software that manages memory, terminals, virtualization, containers (eg. DMA over IB, tmux, QEMU, containerd).
Sometimes this category is extended to system monitoring or higher-level management tools that still give some kind of general service similar to the one provided by the operating system. Think about SAR or mdadm kind of tools. Or, this could also be testing of operating system services (eg. FIO).
Sometimes, this can also mean some kind of administrative tools that perform either more high-level management of operating system (eg. yum, the RHEL package manager), or management of groups of operating systems. Cloud tools can fall into this category (eg. boto3 AWS client). But, this is kind of stretching the definition.
----
So, as per usual in the field of programming... we don't have an authoritative source and a definition for a widely used term. You just have to accept (at least for now), that different people mean different (but often significantly overlapping) things when they use the term and ask more questions to refine what they mean by it.
These days? A programmer that does anything but CRUD for web apps.
In the before times the terminology came from system 360 and descendent mainframe systems where the system programmers tended to be intimately involved with the deployment and programming of the operating system and associated "exits", and such tasks tended to presume some working knowledge of assembly language (operating systems were very crude at that time...and many shops tended to "customize" them if that makes sense...you would sometimes have serious problems with operating system level things and at that time the generic response would be "contact your systems programmer", who would either fix it or get in touch with IBM...so TLDR is basically a sysadmin that is good at assembly). Big companies could afford to have systems programmers on staff and needed them because every shop was different and computers were very custom and crude at that point in history.
That's where the terminology came from originally but now it has expanded and can mean different things.
The "systems programmers" terminology was mainly just a differentiation from the more generic "application programmers" (who would probably program in COBOL or something similar, doing business related tasks) or "system operators" (who would not usually be programmers at all, and would do a lot of what we would now consider sysadmin work).
Nowadays it just means anything that isn't bog standard CRUD or frontend web app stuff. The terminology has evolved but has a somewhat similar meaning to when it originated. It's tough to understand exactly without the historical context which is why I have included that.
For obvious reasons, this has some overlap with the more modern definition of "programmers that build systems that other programmed then use". Because the application programmers on those mainframe systems would be relying on the systems programmers to not screw up their assembly wizardry or else everything would fall apart.
