What’s a System Engineer
There is still an active discussion of what System Engineering and the system engineer is all about. I found a very interesting post on the matter here.
The historical roots have created some of the differences in these definitions of “systems engineering.” For example, the INCOSE definition comes from its roots in electrical engineering and its early application in places like Bell Labs, the defense industry, and space programs.
All systems engineering definitions and all industrial engineering programs share a focus on a set of methods and techniques, although the particular methods and techniques vary.
This article here is not meant to totally resolute the matter, but to bring a personal perspective to the profession.
Wikipedia starts telling us that:
Systems engineering is an interdisciplinary field of engineering focusing on how complex engineering projects should be designed and managed over their life cycles. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more difficult when dealing with large, complex projects. Systems engineering deals with work-processes and tools to manage risks on such projects, and it overlaps with both technical and human-centered disciplines such as control engineering,industrial engineering, organizational studies, and project management.
Yet, there is, among a lot of other definitions (including from NASA), the more succinct definition given by INCOSE, stating that Systems engineering:
An interdisciplinary approach and means to enable the realization of successful systems.
We can already see fuzzy definitions, relying on very abstract ideas. But, however difficult it would be to exactly define, the discipline is starting from the end result, then finding and applying the proper actions and specific methodologies that enable the project to get there.
So, how do the System Engineer fit in here? Surely, we are not sales consultant or network maintenance engineers. It’s nothing more true that we have the customer’s needs and interests in the forefront of our minds. From this point of view, one can say that we are the representatives of our company that sells computer equipment.
Then, it’s obvious, the System Engineer is the one that performs the systems engineering activities. He should be a generalist, yet technically proficient when coming to interlink all disciplines and components that concur to form a system. That means a solid knowledge (though not an intimate one) is required in all engineering fields, being it software, electronics, mechanical physics or hydraulics, as well as processes and specific methods and tools. In short, she needs to understand how things work, and more, have strong abilities and vision to have them all work together as one. That sometimes means the need to process and cope with a huge amount of data, existing know-how and new requirements to the end of finding the optimum, and ideally simplest, technical solution.
We saw so far System Engineering is supposed to be an interdisciplinary approach, integrating product development activities as: Software, Hardware, Mechanical implementation, as well as some other rather not so exact domains as people, the customer interfacing, legislation, quality orientation while still pushing for results at reasonable costs.
One needs to trust and cooperate well with his team, as he will rely on expert knowledge and realization, while he defines the needs for each component, refining their interfaces to ensure that at the end the entire thing will work as a whole.
Yes, we need to understand what our colleagues are explaining, but our job is to balance through cost and performance, through distributing the feature’s implementation over different functional blocks and/or components. This point of view is drawing us closer to complement the project manager activities, but still not having lost the accentuated technical focus. This is one reason why some companies merge the two jobs in one performed by the technical project manager.
Systems engineering is a highly hands-on role. The System Engineer helps a company develop and maintain the many different technical components that make up a system. 
Following LinkedIn group discussions, I found one regarding the role of a System Engineer. One answer stated as follows:
A good SE, I would expect, also has a wider knowledge base than most. In my current job I am dealing with issues of Pressure Vessels, Vacuum Systems, Explosive Gases and Atmospheres, Bottle Gas Safety, Cryogenics, Electrical, Electronic and Programmable Control Systems (I started in Electronics). I get regular refresher training on the majority of those aspects to keep up with the current state of legislation. Because of the industry I work with we do have to have an eye to the eventual disposal for most of our materials. 
A slightly deeper view on the System Engineer
As one can differentiate System Engineering in two major activities: Requirements Engineering and Architecture (Design – depending on point of view), so a System Engineer can play the role of Requirements Engineer or Architect; or both.
Requirements engineering (RE) is a systems and software engineering process which covers all of the activities involved in discovering, documenting and maintaining a set of requirements for a computer-based system. 
Shortly then, the Requirements Engineer does activities like:
- Requirements management: managing changes to the requirements as the system is developed, structure and categorize requirements, prioritize them and creates traceability.
- Requirement development: copes with requirements elicitation (uncovering and documenting requirement from different sources), their analysis and negotiation, specification and requirements validation.
The Architect (or designer) is the one who establishes the technical solution for implementing the requirements. A lot more information about the topic, viewing the role in different contexts, may be found here.
I found a very interesting thread regarding what an architect is, on the Microsoft forums. A short excerpt from it:
I would expect someone who is expert in problem solving, can see the most effective way forward for a solution, from a business and technology perspective.
I would see an architect as having excellent communication skills, the ability to translate a business strategy into a set of software solutions. I would expect an architect to be able to see risk and mitigate it. I would expect an architect to be able to communicate both to the business and the a technical audience.
I would expect an architect to be able to have knowledge of the technical implementation details rather than just a theoretical or paper based view of the solution. I would expect that architect to, given their knowledge be able to foresee any difficulties in maintainability, implementation, usability, extensibility and so on and be able to come up with the best compromise on these.
I would expect an architect to also be inventive and able to imagine different ways to do things, including those that may not yet have been attempted by any other architects, to be able to step back and look at the problem, and come up with the greatest solution.
There’s more, but I’ll let someone else have a go at this now!
Martin Platt. 
So then, Systems Engineering is a multifaceted discipline, involving human, organizational, and various technical variables that work together to create complex systems.
A System Engineer is somebody with strong analytical skills, able to grasp the entire problem in its whole, able to see in perspective, mature and goal oriented to get things done, a good communicator with advanced people skills to gain the respect and cooperation of team and customer; all these backed by a high volume of knowledge and experience in his field.
 Missouri State University – What is systems engineering? Jane M. Fraser, Colorado State University-Pueblo, Abhijit Gosavi, Missouri S & T
 Wikipedia – Systems engineering
 NASA – Systems Engineering and Integration
 INCOSE – What is System Engineering?
 About.com – Systems Engineer
 LinkedIn – Group discussions
 Kotonya G. and Sommerville, I. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley & Sons. 1998
 MSDN Forums – Call yourself an Architect?