One line in a job ad often mixes two different jobs
CNC job descriptions often include a familiar formula: looking for a CNC operator, preferably with the ability to write programs. Sometimes that requirement is reasonable. In a small shop, one person may run parts, make simple edits, and understand where the program interferes with normal work. In hiring, however, that phrase often becomes too convenient. It hides a question the employer has not answered in advance: is the company looking for an operator, a programmer, or someone expected to cover both risks at once?
The difference is visible not in the job title, but in what the employee will be responsible for during an ordinary working day. The operator holds the process at the machine: loading the blank, checking dimensions, making corrections within allowed limits, reacting to tool wear, keeping the workstation in order, and maintaining the stability of the run. The programmer is responsible for something else: machining logic, toolpaths, safe moves, the postprocessor, and the connection between the program, the fixture, and the real limits of the machine.
When these roles are mixed carelessly, the vacancy looks stronger than the real position. Then the unpleasant part begins: the programmer does not want to stand all day on a repeat run, the operator gets nervous about the expectation of independent CAM decisions, and the supervisor receives not a universal employee, but an argument about “who was supposed to foresee this”.
Operator skills are tested around the process, not in theory
A good CNC machine operator does not have to be the author of complex NC programs. Their value is often elsewhere: they notice when the process starts to drift and prevent a small issue from turning into a batch of scrap. That sounds less impressive in a resume, but on the shop floor this discipline becomes visible quickly.
When hiring an operator, it is worth testing the practical sequence of work. How does the person prepare the workstation before the start? What is checked on the first part? Which dimensions are controlled more often than others? How do they understand that the tool no longer holds size? What do they do if the blank sits differently than usual? A good answer usually does not sound like a lecture. It sounds like a working routine with a habit of slowing down in dangerous places.
One important detail: an operator may work confidently with G-code at the level of reading, finding the needed block, understanding offsets, and stopping safely. That still does not make them a programmer. The employer has to decide whether this level is enough for the vacancy, or whether the company truly needs someone who will create and debug the program from scratch.
Programmer skills are tested through decisions made before the machine
A CNC programmer may rarely stand at the machine all day, but their mistake reaches the shop floor in a very physical form: unnecessary air cutting, an awkward tool change, a weak roughing strategy, collision risk, or a critical dimension checked too late. That is why testing a programmer should not be limited to the name of a CAM system or a list of controls.
The employer needs to understand how the specialist thinks before the first start. What input data do they need from the process engineer or supervisor? How do they choose the operation sequence? Where do they build in safe moves? How do they check the program before sending it to the machine? What do they do if the postprocessor outputs code that formally runs but is inconvenient for real setup?
Sometimes an applicant speaks confidently about CAM but explains poorly what will happen to the part after clamping. That is a weak signal for a programmer. A program does not live separately from the blank, fixture, tool, and inspection. If the person sees only the screen, the shop will later pay with setup time.
Where the roles overlap, and why that is not a reason to test everything at once
There is a natural shared zone between operator and programmer. Both should understand basic machining logic, movement safety, the meaning of offsets, tool influence, and the importance of inspection. In a strong team, the operator can tell the programmer where the program is inconvenient at the machine, and the programmer should respect that signal instead of treating it as resistance.
But overlap does not mean identical testing. If an operator is given a full programming task, the company may lose a good production worker simply because it tested the wrong job. If a programmer is evaluated only by the speed of starting a proven series, the employer may miss someone who designs machining well but does not look impressive in operator routine.
This is especially visible in companies where “universal specialist” has become a substitute for a normal process description. Versatility is useful when it is honestly defined: which operations the person performs alone, where a check is required, which changes are forbidden without approval, and who owns the final program version. Without these boundaries, versatility turns into an expectation that the new employee will guess the internal rules.
Which checks should be separated
For an operator, a short practical check around process stability is more useful:
- describe the first-part start and the control points;
- explain how they react to gradual dimensional drift;
- walk through a situation with tool wear or unstable clamping;
- show understanding of offsets, cycle stop, and passing information to the next shift.
For a programmer, the check should be different:
- review a drawing or 3D model at the level of machining strategy;
- explain the choice of operation sequence and tools;
- show how they verify the program before sending it to the machine;
- describe what data they need in order not to program blindly.
These checks can be done without exposing another company’s drawings and without a long exam. The point is not to make the test look impressive, but to see working logic. The operator should show reliability around the process. The programmer should show that their decisions do not collapse when they meet a real machine.
A weak job description is expensive for both sides
If an employer writes “CNC operator/programmer” without explaining the share of tasks, it increases noise in the applications. Some applicants will expect programming and growth, others will expect stable operator work, and others will agree to everything in the text and then start clarifying boundaries only after they arrive. That is a bad time for clarification: the machine is already waiting, the shift is already planned, and the supervisor is already hoping to close a gap in the schedule.
The vacancy should state honestly what matters most in the first months. For example: 80% operator work on a production run and 20% simple edits; independent programming only after approval; or the reverse, where the main task is program preparation and machine work is needed for debugging and connection with production. This kind of detail may reduce the number of applications, but it improves the chance that the right people respond.
Here the employer has a simple guide: if failure in this position will stop the machine, test operator stability. If failure will create a dangerous or unusable program, test programming thinking. If both risks matter, separate them clearly instead of hiding them inside one attractive phrase.
Salary expectations also depend on separating the roles
A mixed vacancy almost always affects pay. If the company wants an operator who sometimes corrects a program, that is one level of responsibility. If it needs a person who develops the machining process, debugs code, owns toolpath safety, and still runs the machine, that is a different position. Calling it an operator job and paying it like ordinary series running usually does not work for long.
The applicant also needs to understand the boundaries. Being able to start programs and change offsets is not the same as full programming work. And being able to create CAM programs does not remove the need to understand how the program will live on the machine. Honest separation of skills helps not only the employer, but also the person choosing where to grow next.
In CNC Passport, these differences can be reflected in a profile and in verified experience when the company and specialist need to show real independence instead of a general label. But the logic starts before any platform: first, name the job correctly.
Separate responsibility first, then choose the test
The best test will not save a vacancy if the employer has not decided who they are looking for. Before the interview, it is worth writing down three things briefly: which tasks the employee will do every day, which decisions they can make without approval, and which errors they are truly responsible for. After that, it becomes clear which skills should be tested separately.
A CNC operator and CNC programmer can be the same person, but that does not make the roles identical. When the company distinguishes the process at the machine from decisions made before the machine, hiring becomes calmer. There are fewer accidental expectations, less irritation after the start, and fewer situations where a good specialist turns out to be “wrong” only because the vacancy tried to be everything at once.