A table isn't many to many. Relationships between tables are many to many, but since we can't represent a many to many relationship in a database, we have to devolve that relationship into two 1 to many relationships.
So if you have employees and training courses, you need an employees table, a courses table, and an employee-courses table.
The employees table is not directly related to the courses table. It's the employee-courses table that provides the relationships.
So one employee can take zero, or any number if courses (1 to many) and courses can be taken by many employees (1 to many).
The employee courses table holds the employee ID and the course ID, and maybe the course date and other information about that particular attendance.
It sounds like you are standardising the course requirements for different jobs. I presume you then give these different jobs to different employees.
So you get employees job-description and employee-jobs. You then join the skills by having the job-descriptions linked to a trading-courses table.
So I can see an issue where you have a product awareness course, say, that is required for multiple jobs, and you only need an employee to take that course once. In that case you would need to redesign your table relationships to help manage that schema, as otherwise there might indirectly be duplication of courses an employee needs to take. Offhand, I'm not sure of the right database structure to achieve the best outcome.
I think we need to understand precisely how your tables relate to one another to guide you, though. Does that all make sense?
So this isn't really "forms" at all. It's tables, because if you get the table structure right, the form design should flow from the table design.